Deadline Cloud のセキュリティのベストプラクティス - AWS Deadline クラウド
データ保護IAM アクセス許可ユーザーおよびグループとしてジョブを実行するネットワークジョブデータFarm 構造ジョブアタッチメントキューカスタムソフトウェアバケットワーカーホストワークステーション

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Deadline Cloud のセキュリティのベストプラクティス

AWS Deadline Cloud (Deadline Cloud) には、独自のセキュリティポリシーを開発および実装する際に考慮すべきさまざまなセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に必ずしも適切または十分でない可能性があるので、処方箋ではなく、あくまで有用な考慮事項とお考えください。

注記

多くのセキュリティトピックの重要性の詳細については、「 責任共有モデル」を参照してください。

データ保護

データ保護の目的で、 AWS アカウント 認証情報を保護し、 AWS Identity and Access Management () を使用して個々のアカウントを設定することをお勧めしますIAM。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:

  • 各アカウントで多要素認証 (MFA) を使用します。

  • SSL/TLS を使用して AWS リソースと通信します。1TLS.2 が必要で、1.3 TLS をお勧めします。

  • を使用して APIとユーザーアクティビティのログ記録を設定します AWS CloudTrail。

  • AWS 暗号化ソリューションと、 内のすべてのデフォルトのセキュリティコントロールを使用します AWS サービス。

  • Amazon S3 (Amazon Simple Storage Service) に保存されている個人情報の発見と保護を支援する Amazon Macie などのアドバンストマネージドセキュリティサービスを使用します。

  • コマンドラインインターフェイスまたは を介して にアクセスする AWS ときに FIPS 140-2 検証済みの暗号化モジュールが必要な場合はAPI、FIPSエンドポイントを使用します。利用可能なFIPSエンドポイントの詳細については、「連邦情報処理規格 (FIPS) 140-2」を参照してください。

顧客のアカウント番号などの機密の識別情報は、[名前] フィールドなどの自由形式のフィールドに配置しないことを強くお勧めします。これは、コンソール、、または AWS AWS サービス を使用して Deadline Cloud または他の を使用する場合API AWS CLIも同様です AWS SDKs。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 アクセス許可を継承します。

フリートとキューの設定を組み合わせて、セキュリティ体制を確立します。キュー側では、「ユーザーとして実行されるジョブ」とIAMロールを指定して、キューのジョブに OS と AWS アクセス許可を使用できます。フリートは、特定のキューに関連付けられているときにキュー内でジョブを実行するインフラストラクチャ (ワーカーホスト、ネットワーク、マウントされた共有ストレージ) を定義します。ワーカーホストで使用可能なデータは、1 つ以上の関連付けられたキューのジョブによってアクセスされる必要があります。ユーザーまたはグループを指定すると、ジョブ内のデータを他のキュー、インストールされている他のソフトウェア、またはワーカーホストにアクセスできる他のユーザーから保護できます。キューにユーザーがない場合、キューはエージェントユーザーとして実行され、任意のキューユーザーを偽装 (sudo) できます。このようにして、ユーザーのないキューは別のキューに権限をエスカレートできます。

ネットワーク

トラフィックが傍受またはリダイレクトされないようにするには、ネットワークトラフィックがルーティングされる方法と場所を保護することが重要です。

ネットワーク環境を次の方法で保護することをお勧めします。

  • Amazon Virtual Private Cloud (Amazon VPC) サブネットルートテーブルを保護して、IP レイヤートラフィックのルーティング方法を制御します。

  • ファームまたはワークステーションのセットアップで Amazon Route 53 (Route 53) をDNSプロバイダーとして使用している場合は、Route 53 への安全なアクセスを確保してくださいAPI。

  • オンプレミスのワークステーションやその他のデータセンターを使用する AWS など、 の外部で Deadline Cloud に接続する場合は、オンプレミスのネットワークインフラストラクチャを保護します。これには、ルーター、スイッチ、その他のネットワークデバイスのDNSサーバーとルートテーブルが含まれます。

ジョブとジョブデータ

Deadline Cloud ジョブは、ワーカーホストのセッション内で実行されます。各セッションはワーカーホストで 1 つ以上のプロセスを実行します。通常、出力を生成するにはデータを入力する必要があります。

このデータを保護するには、キューを使用してオペレーティングシステムユーザーを設定できます。ワーカーエージェントはキュー OS ユーザーを使用してセッションサブプロセスを実行します。これらのサブプロセスは、キュー OS ユーザーのアクセス許可を継承します。

これらのサブプロセスがアクセスするデータへのアクセスを保護するためのベストプラクティスに従うことをお勧めします。詳細については、責任共有モデルを参照してください。

Farm 構造

Deadline Cloud フリートとキューは、さまざまな方法で配置できます。ただし、特定の手配にはセキュリティ上の影響があります。

ファームは、フリート、キュー、ストレージプロファイルなど、他のファームと Deadline Cloud リソースを共有できないため、最も安全な境界の 1 つです。ただし、ファーム内で外部 AWS リソースを共有することはでき、セキュリティ境界が侵害されます。

適切な設定を使用して、同じファーム内のキュー間にセキュリティ境界を確立することもできます。

次のベストプラクティスに従って、同じファームに安全なキューを作成します。

  • フリートを同じセキュリティ境界内のキューにのみ関連付けます。次の点に注意してください。

    • ワーカーホストでジョブが実行された後、一時ディレクトリやキューユーザーのホームディレクトリなどにデータが残される可能性があります。

    • ジョブの送信先のキューに関係なく、同じ OS ユーザーがサービス所有のフリートワーカーホストですべてのジョブを実行します。

    • ジョブがワーカーホストで実行されているプロセスを離れ、他のキューのジョブが実行中の他のプロセスを監視できるようになる場合があります。

  • 同じセキュリティ境界内のキューのみが、ジョブアタッチメントの Amazon S3 バケットを共有していることを確認します。

  • 同じセキュリティ境界内のキューのみが OS ユーザーを共有していることを確認します。

  • ファームに統合されている他の AWS リソースを境界に保護します。

ジョブアタッチメントキュー

ジョブアタッチメントは、Amazon S3 バケットを使用するキューに関連付けられています。

  • ジョブアタッチメントは、Amazon S3 バケットのルートプレフィックスに対して書き込みと読み取りを行います。このルートプレフィックスは、 CreateQueueAPI呼び出しで指定します。

  • バケットには対応する がありQueue Role、キューユーザーにバケットとルートプレフィックスへのアクセスを許可するロールを指定します。キューを作成するときは、ジョブアタッチメントバケットとルートプレフィックスとともに Queue Role Amazon リソースネーム (ARN) を指定します。

  • AssumeQueueRoleForRead、、および AssumeQueueRoleForWorkerAPIオペレーションへの許可された呼び出しはAssumeQueueRoleForUser、 の一時的なセキュリティ認証情報のセットを返しますQueue Role。

キューを作成し、Amazon S3 バケットとルートプレフィックスを再利用すると、情報が不正な当事者に開示されるリスクがあります。例えば、QueueA と QueueB は同じバケットとルートプレフィックスを共有します。安全なワークフローでは、ArtistA は QueueA にアクセスできますが、QueueB にはアクセスできません。ただし、複数のキューがバケットを共有する場合、ArtistA は QueueB データ内のデータにアクセスできます。 QueueA

コンソールは、デフォルトで安全なキューを設定します。キューが共通のセキュリティ境界の一部でない限り、Amazon S3 バケットとルートプレフィックスの個別の組み合わせがあることを確認します。

キューを分離するには、バケットとルートプレフィックスへのキューアクセスQueue Roleのみを許可するように を設定する必要があります。次の例では、各 を置き換えます。placeholder リソース固有の情報を入力します。

{
  "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/*"
    }
  ]
}

また、ロールに信頼ポリシーを設定する必要があります。次の例では、placeholder リソース固有の情報を含む テキスト。

{
  "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 バケット

に次のステートメントを追加してQueue Role、Amazon S3 バケット内のカスタムソフトウェアにアクセスできます。次の例では、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 Simple Storage Service ユーザーガイドのAmazon S3 のセキュリティのベストプラクティス」を参照してください。

ワーカーホスト

ワーカーホストを保護して、各ユーザーが割り当てられたロールに対してのみオペレーションを実行できるようにします。

ワーカーホストを保護するために、次のベストプラクティスをお勧めします。

  • これらのキューに送信されたジョブが同じセキュリティ境界内にある場合を除き、複数のキューで同じjobRunAsUser値を使用しないでください。

  • ワーカーエージェントが実行される OS ユーザーの名前jobRunAsUserにキューを設定しないでください。

  • 目的のキューワークロードに必要な最小特権の OS アクセス許可をキューユーザーに付与します。エージェントプログラムファイルやその他の共有ソフトウェアを操作するためのファイルシステムの書き込みアクセス許可がないことを確認します。

  • のルートユーザーLinuxと Administrator が所有するアカウントのみがWindows所有し、ワーカーエージェントプログラムファイルを変更できることを確認します。

  • Linux ワーカーホストでは、ワーカーエージェントユーザーがキューユーザーとしてプロセスを起動/etc/sudoersできるようにするumaskオーバーライドを で設定することを検討してください。この設定は、他のユーザーがキューに書き込まれたファイルにアクセスできないようにするのに役立ちます。

  • 信頼できる個人に、ワーカーホストへの最小特権アクセスを付与します。

  • ローカルDNSオーバーライド設定ファイル (/etc/hosts LinuxC:\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 で特に使用されるソフトウェアが含まれます。