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

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

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

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

注記

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

データ保護

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

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

  • SSL/TLS を使用して AWS リソースと通信します。1.2 が必要でTLS、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 ユーザーのアクセス許可を継承します。

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

ファーム構造

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

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 Simple Storage Service ユーザーガイドAmazon S3 のセキュリティのベストプラクティス」を参照してください。

ワーカーホスト

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

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

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

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

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

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

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

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

  • アクセス許可をローカルDNSオーバーライド設定ファイル (/etc/hosts の Linux および C:\Windows\system32\etc\hostsの Windows) と を使用して、ワークステーションとワーカーホストオペレーティングシステムにテーブルをルーティングします。

  • ワークステーションとワーカーホストオペレーティングシステムDNSの設定に対するアクセス許可を制限します。

  • オペレーティングシステムとインストールされているすべてのソフトウェアに定期的にパッチを適用します。このアプローチには、送信者、アダプター、ワーカーエージェント、OpenJD パッケージなど。

  • に強力なパスワードを使用する Windows queue.jobRunAsUser

  • キュー のパスワードを定期的にローテーションしますjobRunAsUser。

  • への最小特権アクセスを確保する Windows パスワードは、未使用のシークレットをシークレットし、削除します。

  • 今後実行するスケジュールコマンドをキューjobRunAsUserに付与しないでください。

    • On Linux、これらのアカウントによる cronおよび へのアクセスを拒否しますat。

    • On Windows、これらのアカウントによる へのアクセスを拒否します。Windows タスクスケジューラ。

注記

オペレーティングシステムとインストールされたソフトウェアに定期的にパッチを適用する重要性の詳細については、「 責任共有モデル」を参照してください。

ワークステーション

Deadline Cloud にアクセスできるワークステーションを保護することが重要です。このアプローチは、Deadline Cloud に送信するジョブが、 に請求される任意のワークロードを実行できないようにするのに役立ちます AWS アカウント。

アーティストワークステーションを保護するには、次のベストプラクティスをお勧めします。詳細については、 責任共有モデルを参照してください。

  • Deadline Cloud など AWS、 へのアクセスを提供する永続認証情報を保護します。詳細については、IAM「 ユーザーガイド」のIAM「ユーザーのアクセスキーの管理」を参照してください。

  • 信頼できる安全なソフトウェアのみをインストールします。

  • ID プロバイダーとフェデレーションするユーザーに、一時的な認証情報 AWS を使用して へのアクセスを要求します。

  • Deadline Cloud 送信者プログラムファイルに安全なアクセス許可を使用して、改ざんを防止します。

  • 信頼できる個人にアーティストワークステーションへの最小特権アクセスを付与します。

  • Deadline Cloud Monitor を通じて取得した送信者とアダプターのみを使用してください。

  • アクセス許可をローカルDNSオーバーライド設定ファイル (/etc/hosts の Linux また、macOS、 および C:\Windows\system32\etc\hostsの Windows) と を使用して、ワークステーションとワーカーホストオペレーティングシステムにテーブルをルーティングします。

  • ワークステーションとワーカーホストオペレーティングシステム/etc/resolve.confのアクセス許可を に制限します。

  • オペレーティングシステムとインストールされているすべてのソフトウェアに定期的にパッチを適用します。このアプローチには、送信者、アダプター、ワーカーエージェント、OpenJD パッケージなど。