翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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 レイヤートラフィックのルーティング方法を制御します。
-
ファームまたはワークステーションのセットアップでDNSプロバイダーとして Amazon Route 53 (Route 53) を使用している場合は、Route 53 へのアクセスを保護しますAPI。
-
オンプレミスのワークステーションやその他のデータセンターなど、 の外部 AWS で Deadline Cloud に接続する場合は、オンプレミスのネットワークインフラストラクチャを保護します。これには、ルーター、スイッチ、その他のネットワークデバイスのDNSサーバーとルートテーブルが含まれます。
ジョブとジョブデータ
Deadline Cloud ジョブは、ワーカーホストのセッション内で実行されます。各セッションはワーカーホストで 1 つ以上のプロセスを実行します。通常、出力を生成するにはデータを入力する必要があります。
このデータを保護するには、キューを使用してオペレーティングシステムユーザーを設定できます。ワーカーエージェントはキュー OS ユーザーを使用してセッションサブプロセスを実行します。これらのサブプロセスは、キュー OS ユーザーのアクセス許可を継承します。
ベストプラクティスに従って、これらのサブプロセスアクセスのデータへのアクセスを保護することをお勧めします。詳細については、責任共有モデル
ファーム構造
Deadline Cloud フリートとキューは、さまざまな方法で配置できます。ただし、特定の手配にはセキュリティ上の影響があります。
ファームは、フリート、キュー、ストレージプロファイルなどの他のファームと Deadline Cloud リソースを共有できないため、最も安全な境界の 1 つです。ただし、ファーム内で外部 AWS リソースを共有でき、セキュリティ境界が侵害されます。
適切な設定を使用して、同じファーム内のキュー間にセキュリティ境界を確立することもできます。
同じファームで安全なキューを作成するには、次のベストプラクティスに従います。
-
フリートを同じセキュリティ境界内のキューにのみ関連付けます。次の点に注意してください:
-
ワーカーホストでジョブが実行された後、一時ディレクトリやキューユーザーのホームディレクトリなどにデータが残っている場合があります。
-
ジョブの送信先のキューに関係なく、同じ OS ユーザーがサービス所有のフリートワーカーホストですべてのジョブを実行します。
-
ジョブがワーカーホストで実行されているプロセスから離れ、他のキューからのジョブが実行中の他のプロセスを監視できるようになる場合があります。
-
-
同じセキュリティ境界内のキューのみが、ジョブアタッチメントの Amazon S3 バケットを共有していることを確認します。
-
同じセキュリティ境界内のキューのみが OS ユーザーを共有していることを確認します。
-
ファームに統合されている他の AWS リソースを境界に保護します。
ジョブアタッチメントキュー
ジョブアタッチメントは、Amazon S3 バケットを使用するキューに関連付けられています。
-
ジョブアタッチメントは、Amazon S3 バケットのルートプレフィックスに対して書き込みと読み取りを行います。このルートプレフィックスは
CreateQueue
API呼び出しで指定します。 -
バケットには対応する があり
Queue Role
、キューユーザーにバケットとルートプレフィックスへのアクセスを許可するロールを指定します。キューを作成するときは、ジョブアタッチメントバケットとルートプレフィックスとともにQueue Role
Amazon リソースネーム (ARN) を指定します。 -
AssumeQueueRoleForRead
、、およびAssumeQueueRoleForWorker
APIオペレーションへの許可された呼び出しは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 バケット内のカスタムソフトウェアにアクセスできます。次の例では、 を S3 バケットの名前SOFTWARE_BUCKET_NAME
に置き換えます。
"Statement": [ { "Action": [ "s3:GetObject", "s3:ListBucket" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::
SOFTWARE_BUCKET_NAME
", "arn:aws:s3:::SOFTWARE_BUCKET_NAME
/*" ] } ]
Amazon S3 セキュリティのベストプラクティスの詳細については、Amazon S3 のセキュリティのベストプラクティス」を参照してください。
ワーカーホスト
ワーカーホストを保護して、各ユーザーが割り当てられたロールに対してのみオペレーションを実行できるようにします。
ワーカーホストを保護するには、次のベストプラクティスをお勧めします。
-
これらのキューに送信されたジョブが同じセキュリティ境界内にある場合を除き、複数のキューで同じ
jobRunAsUser
値を使用しないでください。 -
キューを
jobRunAsUser
、ワーカーエージェントが実行される OS ユーザーの名前に設定しないでください。 -
目的のキューワークロードに必要な最小特権の 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 and macOS、 およびC:\Windows\system32\etc\hosts
オン Windows)、および を使用して、ワークステーションとワーカーホストオペレーティングシステムにテーブルをルーティングします。 -
ワークステーションとワーカーホストオペレーティングシステム
/etc/resolve.conf
のアクセス許可を に制限します。 -
オペレーティングシステムとインストールされているすべてのソフトウェアに定期的にパッチを適用します。このアプローチには、送信者、アダプター、ワーカーエージェント、OpenJD パッケージなど。