데드라인 클라우드의 보안 모범 사례 - AWS 데드라인 클라우드
데이터 보호IAM 권한사용자 및 그룹으로 작업 실행네트워킹Job 데이터팜 구조Job 첨부 대기열사용자 지정 소프트웨어 버킷워커 호스트워크스테이션

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

데드라인 클라우드의 보안 모범 사례

AWS 데드라인 클라우드 (Deadline Cloud) 는 자체 보안 정책을 개발하고 구현할 때 고려해야 할 여러 보안 기능을 제공합니다. 다음 모범 사례는 일반적인 지침이며 완벽한 보안 솔루션을 나타내지는 않습니다. 이러한 모범 사례는 환경에 적절하지 않거나 충분하지 않을 수 있으므로 참고용으로만 사용해 주십시오.

참고

여러 보안 주제의 중요성에 대한 자세한 내용은 공동 책임 모델을 참조하십시오.

데이터 보호

데이터 보호를 위해 AWS Identity and Access Management (IAM) 을 AWS 계정 사용하여 자격 증명을 보호하고 개별 계정을 설정하는 것이 좋습니다. 이렇게 하면 개별 사용자에게 자신의 직무를 충실히 이행하는 데 필요한 권한만 부여됩니다. 또한 다음과 같은 방법으로 데이터를 보호하는 것이 좋습니다.

  • 각 계정에 멀티 팩터 인증 설정(MFA)을 사용하세요.

  • SSL/TLS를 사용하여 리소스와 통신하세요. AWS TLS 1.2는 필수이며 TLS 1.3를 권장합니다.

  • 를 사용하여 API 및 사용자 활동 로깅을 설정합니다. AWS CloudTrail

  • 포함된 모든 기본 보안 제어와 함께 AWS 암호화 솔루션을 사용하십시오 AWS 서비스.

  • Amazon Simple Storage Service(S3)에 저장된 개인 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용합니다.

  • 명령행 인터페이스 또는 API를 통해 AWS 에 액세스할 때 FIPS 140-2 검증된 암호화 모듈이 필요한 경우, FIPS 엔드포인트를 사용합니다. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 Federal Information Processing Standard(FIPS) 140-2 섹션을 참조하세요.

명칭 필드와 같은 자유 형식 필드에 고객 계정 번호와 같은 중요 식별 정보를 절대 입력하지 마세요. 여기에는 AWS Deadline Cloud를 사용하거나 콘솔 AWS CLI, API 또는 AWS 서비스 AWS SDK를 사용하여 다른 방법으로 작업하는 경우가 포함됩니다. Deadline Cloud 또는 기타 서비스에 입력하는 모든 데이터는 진단 로그에 포함되도록 선택될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 자격 증명 정보를 URL에 포함하지 마십시오.

AWS Identity and Access Management 권한

사용자, AWS Identity and Access Management (IAM) 역할을 사용하고 사용자에게 최소 권한을 부여하여 AWS 리소스에 대한 액세스를 관리합니다. 액세스 자격 증명을 생성, 배포, 교체 및 취소하기 위한 자격 증명 관리 정책 및 절차를 수립하세요. AWS 자세한 설명은 IAM 사용자 가이드의 IAM 모범 사례 섹션을 참조하십시오.

사용자 및 그룹으로 작업 실행

Deadline Cloud에서 대기열 기능을 사용할 때는 OS (운영 체제) 사용자와 기본 그룹을 지정하여 OS 사용자가 대기열 작업에 대한 최소 권한을 갖도록 하는 것이 좋습니다.

'사용자 권한으로 실행' (및 그룹) 을 지정하면 대기열에 제출된 작업의 모든 프로세스는 해당 OS 사용자를 사용하여 실행되며 해당 사용자의 관련 OS 권한을 상속합니다.

플릿과 큐 구성이 결합되어 보안 태세를 확립합니다. 대기열 측에서는 대기열 작업에 OS 및 AWS 권한을 사용하도록 “Job run as user” 및 IAM 역할을 지정할 수 있습니다. 플릿은 특정 대기열에 연결된 경우 대기열 내에서 작업을 실행하는 인프라 (작업자 호스트, 네트워크, 마운트된 공유 스토리지) 를 정의합니다. 작업자 호스트에서 사용 가능한 데이터는 하나 이상의 관련 대기열에 있는 작업자가 액세스할 수 있어야 합니다. 사용자 또는 그룹을 지정하면 다른 대기열, 설치된 다른 소프트웨어 또는 작업자 호스트에 액세스할 수 있는 다른 사용자로부터 작업의 데이터를 보호하는 데 도움이 됩니다. 대기열에 사용자가 없는 경우 모든 대기열 사용자로 가장할 수 있는 에이전트 사용자로 실행됩니다 (sudo). 이렇게 하면 사용자가 없는 대기열도 권한을 다른 대기열로 승격할 수 있습니다.

네트워킹

트래픽이 가로채거나 리디렉션되는 것을 방지하려면 네트워크 트래픽이 라우팅되는 방법과 위치를 보호하는 것이 중요합니다.

다음과 같은 방법으로 네트워킹 환경을 보호하는 것이 좋습니다.

  • Amazon VPC (가상 사설 클라우드) 서브넷 라우팅 테이블을 보호하여 IP 계층 트래픽이 라우팅되는 방식을 제어합니다.

  • 팜 또는 워크스테이션 설정에서 Amazon Route 53 (Route 53) 을 DNS 공급자로 사용하는 경우 Route 53 API에 대한 보안 액세스를 확보하십시오.

  • 온프레미스 워크스테이션이나 다른 데이터 센터를 사용하는 AWS 등 외부에서 Deadline Cloud에 연결하는 경우 모든 온프레미스 네트워킹 인프라를 보호하십시오. 여기에는 라우터, 스위치 및 기타 네트워킹 장치의 DNS 서버 및 라우팅 테이블이 포함됩니다.

작업 및 작업 데이터

데드라인 클라우드 작업은 작업자 호스트의 세션 내에서 실행됩니다. 각 세션은 작업자 호스트에서 하나 이상의 프로세스를 실행합니다. 일반적으로 결과를 생성하려면 데이터를 입력해야 합니다.

이 데이터를 보호하기 위해 운영 체제 사용자를 대기열로 구성할 수 있습니다. 작업자 에이전트는 queue OS 사용자를 사용하여 세션 하위 프로세스를 실행합니다. 이러한 하위 프로세스는 큐 OS 사용자의 권한을 상속합니다.

모범 사례에 따라 이러한 하위 프로세스가 액세스하는 데이터에 대한 액세스를 보호하는 것이 좋습니다. 자세한 내용은 공동 책임 모델을 참조하십시오.

팜 구조

데드라인 클라우드 플릿과 대기열을 다양한 방법으로 정렬할 수 있습니다. 하지만 특정 방식을 사용할 경우 보안에 영향을 미칠 수 있습니다.

팜은 Deadline Cloud 리소스를 플릿, 큐, 스토리지 프로필 등 다른 팜과 공유할 수 없기 때문에 가장 안전한 경계 중 하나입니다. 하지만 팜 내에서 외부 AWS 리소스를 공유할 수 있기 때문에 보안 경계가 손상될 수 있습니다.

적절한 구성을 사용하여 동일한 팜 내의 대기열 간에 보안 경계를 설정할 수도 있습니다.

다음 모범 사례에 따라 동일한 팜에 보안 대기열을 만드십시오.

  • 플릿을 동일한 보안 경계 내의 대기열에만 연결하십시오. 유의할 사항:

    • 작업자 호스트에서 작업이 실행된 후에도 임시 디렉터리나 큐 사용자의 홈 디렉터리 등에 데이터가 남아 있을 수 있습니다.

    • 작업을 제출하는 대기열에 관계없이 동일한 OS 사용자가 서비스 소유의 플릿 작업자 호스트에서 모든 작업을 실행합니다.

    • 작업은 작업자 호스트에서 실행 중인 프로세스를 그대로 둘 수 있으므로 다른 대기열의 작업에서 실행 중인 다른 프로세스를 관찰할 수 있습니다.

  • 동일한 보안 경계 내의 대기열만 작업 첨부용 Amazon S3 버킷을 공유하도록 하십시오.

  • 동일한 보안 경계 내의 대기열만 OS 사용자를 공유하도록 하십시오.

  • 팜에 통합된 다른 모든 AWS 리소스를 경계까지 보호하십시오.

Job 첨부 대기열

작업 첨부는 Amazon S3 버킷을 사용하는 대기열과 연결됩니다.

  • 작업 첨부 파일은 Amazon S3 버킷의 루트 접두사에 쓰고 읽습니다. CreateQueueAPI 호출에서 이 루트 접두사를 지정합니다.

  • 버킷에는 대기열 사용자에게 버킷에 대한 액세스 권한을 부여하는 역할과 루트 접두사를 지정하는 해당 Queue Role 버킷이 있습니다. 대기열을 생성할 때 작업 첨부 파일 버킷 및 루트 접두사와 함께 Queue Role Amazon 리소스 이름 (ARN) 을 지정합니다.

  • AssumeQueueRoleForReadAssumeQueueRoleForUser, 및 AssumeQueueRoleForWorker API 작업에 대한 승인된 호출은 에 대한 임시 보안 자격 증명 세트를 반환합니다. Queue Role

대기열을 생성하고 Amazon S3 버킷과 루트 접두사를 재사용하면 정보가 승인되지 않은 당사자에게 공개될 위험이 있습니다. 예를 들어 QueuEA와 QueueB는 동일한 버킷과 루트 접두사를 공유합니다. 보안 워크플로우에서 Artista는 QueueA에 액세스할 수 있지만 QueueB에는 액세스할 수 없습니다. 하지만 여러 대기열이 버킷을 공유하는 경우 QueueA와 동일한 버킷 및 루트 접두사를 사용하기 때문에 Artista는 QueuEB 데이터의 데이터에 액세스할 수 있습니다.

콘솔은 기본적으로 안전한 대기열을 설정합니다. 대기열에 Amazon S3 버킷과 루트 접두사가 서로 다르게 조합되어 있어야 합니다. 단, 공통 보안 경계에 속하지 않는 한 대기열이 있어야 합니다.

대기열을 격리하려면 버킷과 루트 접두사에 대한 대기열 액세스만 허용하도록 Queue Role 를 구성해야 합니다. 다음 예시에서는 각 플레이스홀더를 리소스별 정보로 바꿉니다.

{
  "Version": "2012-10-17",
  "Statement": [ 
    {
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::JOB_ATTACHMENTS_BUCKET_NAME",
        "arn:aws:s3:::JOB_ATTACHMENTS_BUCKET_NAME/JOB_ATTACHMENTS_ROOT_PREFIX/*"
      ],
      "Condition": {
        "StringEquals": { "aws:ResourceAccount": "ACCOUNT_ID" }
      }
    },
    {
      "Action": ["logs:GetLogEvents"],
      "Effect": "Allow",
      "Resource": "arn:aws:logs:REGION:ACCOUNT_ID:log-group:/aws/deadline/FARM_ID/*"
    }
  ]
}

또한 역할에 신뢰 정책을 설정해야 합니다. 다음 예시에서는 자리 표시자 텍스트를 리소스별 정보로 바꾸십시오.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["sts:AssumeRole"],
      "Effect": "Allow",
      "Principal": { "Service": "deadline.amazonaws.com" },
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "ACCOUNT_ID" },
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:deadline:REGION:ACCOUNT_ID:farm/FARM_ID"
        }
      }
    },
    {
      "Action": ["sts:AssumeRole"],
      "Effect": "Allow",
      "Principal": { "Service": "credentials.deadline.amazonaws.com" },
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "ACCOUNT_ID" },
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:deadline:REGION:ACCOUNT_ID:farm/FARM_ID"
        }
      }
    }
  ]
}

사용자 지정 소프트웨어 Amazon S3 버킷

Amazon S3 버킷의 사용자 지정 소프트웨어에 Queue Role 액세스하기 위해 다음 명령문을 추가할 수 있습니다. 다음 예제에서는 SOFTWARE_BUCKET_NAME을 S3 버킷의 이름으로 대체합니다.

"Statement": [ 
    {
        "Action": [
            "s3:GetObject",
            "s3:ListBucket"
        ],
        "Effect": "Allow",
        "Resource": [
            "arn:aws:s3:::SOFTWARE_BUCKET_NAME",
            "arn:aws:s3:::SOFTWARE_BUCKET_NAME/*"
        ]
    }
]

Amazon S3 보안 모범 사례에 대한 자세한 내용은 Amazon 심플 스토리지 서비스 사용 설명서의 Amazon S3의 보안 모범 사례를 참조하십시오.

워커 호스트

작업자 호스트를 보호하여 각 사용자가 지정된 역할에 대한 작업만 수행할 수 있도록 합니다.

작업자 호스트를 보호하려면 다음 모범 사례를 따르는 것이 좋습니다.

  • 대기열에 제출된 작업이 동일한 보안 경계 내에 있지 않는 한 여러 대기열에 동일한 jobRunAsUser 값을 사용하지 마십시오.

  • 작업자 에이전트가 실행되는 OS 사용자 이름으로 대기열을 jobRunAsUser 설정하지 마십시오.

  • 대기열 사용자에게 의도한 대기열 워크로드에 필요한 최소 권한의 OS 권한을 부여하십시오. 에이전트 프로그램 파일 또는 기타 공유 소프트웨어를 작업할 수 있는 파일 시스템 쓰기 권한이 없는지 확인하십시오.

  • 루트 사용자와 Administrator 소유한 계정만 Linux 작업자 에이전트 프로그램 파일을 Windows 소유하고 수정할 수 있도록 하십시오.

  • Linux작업자 호스트에서는 작업자 에이전트 사용자가 대기열 사용자로 프로세스를 시작할 수 /etc/sudoers 있도록 umask 재정의를 구성하는 것을 고려해 보십시오. 이 구성은 다른 사용자가 대기열에 기록된 파일에 액세스할 수 없도록 하는 데 도움이 됩니다.

  • 신뢰할 수 있는 개인에게 작업자 호스트에 대한 최소 권한 액세스 권한을 부여하세요.

  • 로컬 DNS 재정의 구성 파일 (/etc/hosts온/온) 과 워크스테이션 Linux 및 C:\Windows\system32\etc\hosts 작업자 Windows 호스트 운영 체제의 라우팅 테이블에 대한 권한을 제한합니다.

  • 워크스테이션과 작업자 호스트 운영 체제의 DNS 구성에 대한 권한을 제한합니다.

  • 운영 체제와 설치된 모든 소프트웨어를 정기적으로 패치하십시오. 이 접근 방식에는 제출자, 어댑터, 작업자 에이전트, OpenJD 패키지 등과 같이 Deadline Cloud와 함께 특별히 사용되는 소프트웨어가 포함됩니다.

  • 대기열에는 강력한 비밀번호를 사용하세요. Windows jobRunAsUser

  • 대기열의 비밀번호를 정기적으로 교체하세요jobRunAsUser.

  • 비밀번호에 대한 액세스 권한이 최소한으로 유지되도록 하고 사용하지 않는 Windows 비밀번호는 삭제하세요.

  • 대기열 jobRunAsUser 권한에 미래에 실행할 스케줄 명령을 부여하지 마세요.

    • 아니요Linux, 해당 계정의 cron 및 at 에 대한 액세스를 거부하세요.

    • 켜기Windows, Windows 작업 스케줄러에 대한 이러한 계정 액세스를 거부하십시오.

참고

운영 체제 및 설치된 소프트웨어를 정기적으로 패치하는 것의 중요성에 대한 자세한 내용은 공동 책임 모델을 참조하십시오.

워크스테이션

Deadline Cloud에 액세스할 수 있는 워크스테이션을 보호하는 것이 중요합니다. 이 접근 방식은 Deadline Cloud에 제출하는 모든 작업이 사용자에게 청구되는 임의의 워크로드를 실행할 수 없도록 하는 데 도움이 됩니다. AWS 계정

아티스트 워크스테이션을 보호하려면 다음 모범 사례를 따르는 것이 좋습니다. 자세한 내용은 공동 책임 모델을 참조하세요.

  • Deadline Cloud를 포함하여 액세스를 AWS제공하는 모든 영구 자격 증명을 보호하세요. 자세한 내용은 IAM 사용 설명서의 IAM 사용자의 액세스 키 관리를 참조하세요.

  • 신뢰할 수 있고 안전한 소프트웨어만 설치하세요.

  • 사용자가 ID 공급자와 페더레이션하여 임시 자격 AWS 증명으로 액세스하도록 요구하십시오.

  • Deadline Cloud 제출자 프로그램 파일에 대한 보안 권한을 사용하여 변조를 방지하세요.

  • 신뢰할 수 있는 개인에게 아티스트 워크스테이션에 대한 최소 권한 권한을 부여하세요.

  • Deadline Cloud Monitor를 통해 확보한 제출자와 어댑터만 사용하세요.

  • 워크스테이션과 작업자 호스트 운영 체제의 권한 /etc/hosts 및 라우팅 테이블을 제한하세요.

  • 워크스테이션 및 작업자 호스트 운영 체제에 /etc/resolv.conf 대한 권한을 제한하십시오.

  • 운영 체제와 설치된 모든 소프트웨어를 정기적으로 패치하십시오. 이 접근 방식에는 제출자, 어댑터, 작업자 에이전트, OpenJD 패키지 등과 같이 Deadline Cloud와 함께 특별히 사용되는 소프트웨어가 포함됩니다.