翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Security Lake のセキュリティ のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。 セキュリティは、お客様と AWS お客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウド*の*セキュリティおよびクラウド*内*のセキュリティと説明しています。 + **クラウドのセキュリティ** – AWS は、 で AWS サービスを実行するインフラストラクチャを保護する責任を担います AWS クラウド。 は、お客様が安全に使用できるサービス AWS も提供します。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。Amazon Security Lake に適用されるコンプライアンスプログラムの詳細については、「コンプライアンスプログラム[AWS による対象範囲内のサービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。 + **クラウド内のセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、ユーザーは、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。 このドキュメントは、Security Lake を使用する際に責任共有モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するために Security Lake を設定する方法を説明します。また、Security Lake リソースのモニタリングと保護に役立つ他の AWS サービスの使用方法についても説明します。 **Topics** + [Security Lake の Identity and Access Management](security-iam.md) + [Amazon Security Lake におけるデータ保護](data-protection.md) + [Amazon SECURITY Lake のコンプライアンス検証](compliance-validation.md) + [Security Lake のセキュリティのベストプラクティス](best-practices-overview.md) + [Amazon Security Lake の耐障害性](disaster-recovery-resiliency.md) + [Amazon Security Lake のインフラストラクチャセキュリティ](infrastructure-security.md) + [Security Lake での構成と脆弱性の分析](configuration-vulnerability-analysis.md) + [Amazon Security Lake とインターフェイス VPC エンドポイント (AWS PrivateLink)](security-vpc-endpoints.md) + [Amazon Security Lakeのモニタリング](monitoring-overview.md) # Security Lake の Identity and Access Management AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、Security Lake リソースの使用を*認証* (サインイン) および*承認* (アクセス許可を持つ) できるユーザーをコントロールします。IAM は、追加料金なしで使用できる AWS のサービス です。 **Topics** + [オーディエンス](#security_iam_audience) + [アイデンティティを使用した認証](#security_iam_authentication) + [ポリシーを使用したアクセスの管理](#security_iam_access-manage) + [Security Lake と IAM の連携方法](security_iam_service-with-iam.md) + [Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md) + [AWS Security Lake の マネージドポリシー](security-iam-awsmanpol.md) + [Security Lake のサービスにリンクされたロールの使用](using-service-linked-roles.md) ## オーディエンス AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。 + **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[Amazon Security Lake アイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。 + **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[Security Lake と IAM の連携方法](security_iam_service-with-iam.md)」を参照) + **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照) ## アイデンティティを使用した認証 認証は、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。 AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。 プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。 ### AWS アカウント ルートユーザー を作成するときは AWS アカウント、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *root ユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。 ### フェデレーテッドアイデンティティ ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。 *フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID Directory Service ソースの認証情報 AWS のサービス を使用して にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。 アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。 ### IAM ユーザーとグループ *[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスすることを人間のユーザーに要求する AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。 ### IAM ロール *[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。 IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。 ## ポリシーを使用したアクセスの管理 でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー AWS を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。 管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。 デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。 ### アイデンティティベースのポリシー アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。 アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。 ### リソースベースのポリシー リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。 リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。 ### その他のポリシータイプ AWS は、より一般的なポリシータイプによって付与されるアクセス許可の最大数を設定できる追加のポリシータイプをサポートしています。 + **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。 + **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。 + **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。 + **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。 ### 複数のポリシータイプ 1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。 # Security Lake と IAM の連携方法 IAM を使用して Security Lake へのアクセスを管理する前に、Security Lake で使用できる IAM 機能を確認してください。 **Amazon Security Lake で使用できる IAM の機能** | IAM 機能 | Security Lake サポート | | --- | --- | | [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり | | [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | はい | | [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり | | [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | あり | | [ポリシー条件キー](#security_iam_service-with-iam-id-based-policies-conditionkeys) | あり | | [ACL](#security_iam_service-with-iam-acls) | なし | | [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | あり | | [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり | | [プリンシパルアクセス権限](#security_iam_service-with-iam-principal-permissions) | あり | | [サービスロール](#security_iam_service-with-iam-roles-service) | いいえ | | [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | はい | Security Lake およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要については、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 ## Security Lake のアイデンティティベースのポリシー **アイデンティティベースのポリシーのサポート:** あり アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。 IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。 Security Lakeは、アイデンティティベースのポリシーをサポートします。詳細については、「[Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。 ## Security Lake 内のリソースベースのポリシー **リソースベースのポリシーのサポート:** あり リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。 クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。 Security Lake サービスは、データを保存する Amazon S3 バケットのリソースベースのポリシーを作成します。S3 バケットには、これらのリソースベースのポリシーをアタッチしないでください。Security Lake はユーザーに代わってこれらのポリシーを自動的に作成します。 リソースの例としては、`arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}` の Amazon リソースネーム (ARN) の S3 バケットがあります。この例では、 `region`は Security Lake を有効にした特定の AWS リージョン であり、 `bucket-identifier`は Security Lake がバケットに割り当てるリージョン固有の英数字文字列です。Security Lake は S3 バケットを作成して、そのリージョンのデータを保存します。リソースポリシーは、バケットに対してアクションを実行できるプリンシパルを定義します。Security Lake がバケットにアタッチするリソースベースのポリシー (バケットポリシー) の例を次に示します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}/*", "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}" ], "Condition": { "Bool": { "aws:SecureTransport": "false" } } }, { "Sid": "PutSecurityLakeObject", "Effect": "Allow", "Principal": { "Service": "securitylake.amazonaws.com" }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}/*", "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}" ], "Condition": { "StringEquals": { "aws:SourceAccount": "{DA-AccountID}", "s3:x-amz-acl": "bucket-owner-full-control" }, "ArnLike": { "aws:SourceArn": "arn:aws:securitylake:us-east-1:111122223333:*" } } } ] } ``` ------ リソースベースのポリシーの詳細については、*IAM ユーザーガイド*の「[アイデンティティベースおよびリソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)」を参照してください。 ## Security Lake のポリシーアクション **ポリシーアクションのサポート:** あり 管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。 JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。 Security Lake アクションのリストについては、「*サービス認可リファレンス*」の「[Amazon Security Lake によって定義されたアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)」を参照してください。 Security Lake のポリシーアクションは、アクションの前に以下のプレフィックスを使用します。 ``` securitylake ``` 例えば、ユーザーに特定のサブスクライバーに関する情報へのアクセス許可を付与するには、ユーザーに割り当てるポリシーに `securitylake:GetSubscriber` アクションを含めます。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。Security Lake では、このサービスで実行できるタスクを記述する独自のアクションのセットを定義します。 単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。 ``` "Action": [ "securitylake:action1", "securitylake:action2" ] ``` Security Lake のアイデンティティベースポリシーの例を確認するには、[Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md) を参照してください。 ## Security Lake のポリシーリソース **ポリシーリソースのサポート:** あり 管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。 `Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。 ``` "Resource": "*" ``` Security Lake は、サブスクライバーと AWS アカウント 特定の のデータレイク設定のリソースタイプを定義します AWS リージョン。ARN を使用して、ポリシーでこれらのタイプのリソースを指定できます。 Security Lake リソースタイプのリストとそれぞれの ARN 構文については、「*サービス認可リファレンス*」の「[Amazon Security Lake によって定義されたリソースタイプ](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-resources-for-iam-policies)」を参照してください。リソースタイプごとに指定できるアクションについては、「*サービス認可リファレンス*」の「[Amazon Security Lake で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)」を参照してください。 Security Lake のアイデンティティベースポリシーの例を確認するには、[Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md) を参照してください。 ## Security Lake のポリシー条件キー **サービス固有のポリシー条件キーのサポート:** あり 管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。 `Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。 Security Lake 条件キーのリストについては、「*サービス認可リファレンス*」の「[Amazon Security Lake の条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては、「*サービス認可リファレンス*」の「[Amazon Security Lake で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)」を参照してください。条件キーを使用するポリシーの例については、「[Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。 ## Security Lake のアクセスコントロールリスト (ACL) **ACL のサポート:** なし アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。 Security Lake は ACL をサポートしていないため、Security Lake リソースに ACL をアタッチすることはできません。 ## Security Lake での属性ベースのアクセスコントロール (ABAC) **ABAC (ポリシー内のタグ) のサポート:** あり 属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグをアタッチし、プリンシパルのタグがリソースのタグと一致するときにオペレーションを許可するように ABAC ポリシーを設計できます。 タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。 サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。 ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。 Security Lake リソース、サブスクライバー、および個々の のデータレイク設定 AWS アカウント にタグをアタッチできます AWS リージョン。ポリシーの `Condition` 要素にタグ情報を指定することで、これらの種類のリソースへのアクセスを制御することもできます。Security Lake リソースのタグ付けの詳細については、[Security Lake リソースのタグ付け](tagging-resources.md) を参照してください。リソースのタグに基づいてリソースへのアクセスを制御する ID ベースのポリシーの例については、「[Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。 ## Security Lake で一時的なセキュリティ認証情報を使用する **一時的な認証情報のサポート:** あり 一時的な認証情報は AWS 、リソースへの短期的なアクセスを提供し、フェデレーションまたはスイッチロールの使用時に自動的に作成されます。長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成 AWS することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 Security Lake は、一時的な認証情報の使用をサポートしています。 ## Security Lake の転送アクセスセッション **転送アクセスセッション (FAS) のサポート:** あり 転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。 Security Lake のアクションの中には、他の AWS のサービスにおけるアクションに依存する追加のアクションに対する権限が必要なものもあります。これらのアクションのリストについては、「*サービス認可リファレンス*」の「[Amazon Security Lake によって定義されたアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)」を参照してください。 ## Security Lake のサービスロール **サービスロールのサポート:** なし サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービスに許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。 Security Lake はサービスロールを引き受けたり使用したりしません。ただし、Security Lake を使用するときは AWS Lambda、Amazon EventBridge や Amazon S3 などの関連サービスがサービスロールを引き受けます。ユーザーに代わってアクションを実行するために、Security Lake はサービスリンクロールを使用します。 **警告** サービスロールの権限を変更すると、Security Lake を使用する際に運用上の問題が発生する可能性があります。Security Lake がそのためのガイダンスを提供している場合にのみ、サービス ロールを編集してください。 ## Security Lake のサービスリンクロール **サービスリンクロールのサポート:** あり サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスリンクロールの許可を表示できますが、編集することはできません。 Security Lake は、`AWSServiceRoleForAmazonSecurityLake` という名前の IAM サービスリンクロールを使用します。Security Lake のサービスリンクロールは、顧客に代わってセキュリティデータレイクサービスを運用する権限を付与します。このサービスリンクロールは、Security Lake に直接リンクされている IAM ロールです。これは Security Lake によって事前定義されており、 AWS のサービス Security Lake がユーザーに代わって他の を呼び出すために必要なすべてのアクセス許可が含まれています。Security Lake は、Security Lake AWS リージョン が利用可能なすべての でこのサービスにリンクされたロールを使用します。 Security Lake サービスリンクロールの作成または管理の詳細については、「[Security Lake のサービスにリンクされたロールの使用](using-service-linked-roles.md)」を参照してください。 # Security Lake のアイデンティティベースのポリシーの例 デフォルトでは、ユーザーおよびロールには、Security Lake リソースを作成または変更する許可はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。 これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。 各リソースタイプの ARN の形式など、Security Lake によって定義されたアクションとリソースタイプの詳細については、「*サービス認可リファレンス*」の「[Amazon Security Lake のアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html)」を参照してください。 **Topics** + [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices) + [Security Lake コンソールの使用](#security_iam_id-based-policy-examples-console) + [例: ユーザーにそれぞれのアクセス権限の表示を許可する](#security_iam_id-based-policy-examples-view-own-permissions) + [例: 組織管理アカウントに委任された管理者の指定と削除を許可](#security_iam_id-based-policy-examples-orgs) + [例: タグに基づいてユーザーが購読者をレビューするのを許可する](#security_iam_id-based-policy-examples-review-subscribers-tags) ## ポリシーに関するベストプラクティス ID ベースのポリシーは、あるユーザーがアカウント内で Security Lake リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください: + ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。 + **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。 + **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。 + **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。 + **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。 IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。 ## Security Lake コンソールの使用 Amazon Security Lake コンソールにアクセスするには、許可の最小限のセットが必要です。これらのアクセス許可により、 の Security Lake リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。 AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。 ユーザーとロールがSecurity Lake コンソールを使用できるようにするには、それらにコンソールアクセスを提供する IAM ポリシーを作成します。詳細については、*IAM ユーザーガイド*の「[IAM アイデンティティ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」を参照してください。 ユーザーまたはロールに Security Lake コンソールの使用を許可するポリシーを作成する場合は、そのユーザーまたはロールがコンソールでアクセスする必要のあるリソースに対する適切なアクションをポリシーに必ず含めます。そうしないと、コンソールでそれらのリソースに移動したり、リソースの詳細を表示したりすることができなくなります。 たとえば、コンソールを使用してカスタムソースを追加するには、ユーザーに以下のアクションの実行を許可する必要があります。 + `glue:CreateCrawler` + `glue:CreateDatabase` + `glue:CreateTable` + `glue:StartCrawlerSchedule` + `iam:GetRole` + `iam:PutRolePolicy` + `iam:DeleteRolePolicy` + `iam:PassRole` + `lakeformation:RegisterResource` + `lakeformation:GrantPermissions` + `s3:ListBucket` + `s3:PutObject` ## 例: ユーザーにそれぞれのアクセス権限の表示を許可する この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## 例: 組織管理アカウントに委任された管理者の指定と削除を許可 この例では、 AWS Organizations 管理アカウントのユーザーが組織の委任された Security Lake 管理者を指定して削除することを許可するポリシーを作成する方法を示します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "securitylake:RegisterDataLakeDelegatedAdministrator", "securitylake:DeregisterDataLakeDelegatedAdministrator" ], "Resource": "arn:aws:securitylake:*:*:*" } ] } ``` ------ ## 例: タグに基づいてユーザーが購読者をレビューするのを許可する ID ベースのポリシーでは、条件を使用して、タグに基づいて Security Lake リソースへのアクセスを制御できます。この例では、Security Lake コンソールまたは Security Lake API を使用して、ユーザーがサブスクライバーを確認することを許可するポリシーを作成する方法を示します。ただし、アクセス許可は、サブスクライバの `Owner` タグの値がユーザーのユーザー名である場合にのみ付与されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReviewSubscriberDetailsIfOwner", "Effect": "Allow", "Action": "securitylake:GetSubscriber", "Resource": "arn:aws:securitylake:*:*:subscriber/*", "Condition": { "StringEquals": {"aws:ResourceTag/Owner": "${aws:username}"} } }, { "Sid": "ListSubscribersIfOwner", "Effect": "Allow", "Action": "securitylake:ListSubscribers", "Resource": "*", "Condition": { "StringEquals": {"aws:ResourceTag/Owner": "${aws:username}"} } } ] } ``` ------ この例では、ユーザー名 `richard-roe` を持つユーザーが個々の購読者の詳細を確認しようとすると、購読者には `Owner=richard-roe` または `owner=richard-roe` のタグが付けられる必要があります。それ以外の場合、ユーザーはアクセスを拒否されます。条件キー名では大文字と小文字は区別されないため、条件タグキー `Owner` は `Owner` と `owner` に一致します。条件キーの詳細については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。Security Lake リソースのタグ付けの詳細については、[Security Lake リソースのタグ付け](tagging-resources.md) を参照してください。 # AWS Security Lake の マネージドポリシー AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、多くの一般的なユースケースにアクセス許可を付与するように設計されているため、ユーザー、グループ、ロールにアクセス許可の割り当てを開始できます。 AWS 管理ポリシーは、すべての AWS お客様が使用できるため、特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることに注意してください。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。 AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS マネージドポリシーで定義されたアクセス許可 AWS を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS マネージドポリシーを更新する可能性が高くなります。 詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。 ## AWS マネージドポリシー: AmazonSecurityLakeMetastoreManager Amazon Security Lake は、 AWS Lambda 関数を使用してデータレイク内のメタデータを管理します。この関数を使用すると、Security Lake はデータとデータファイルを含む Amazon Simple Storage Service (Amazon S3) パーティションを AWS Glue Data Catalog テーブルにインデックス化できます。この管理ポリシーには、S3 パーティションとデータファイルを AWS Glue テーブルにインデックス化するための Lambda 関数のすべてのアクセス許可が含まれています。 **アクセス許可の詳細** このポリシーには、以下のアクセス許可が含まれています。 + `logs` – プリンシパルが Lambda 関数の出力を Amazon CloudWatch Logs にログ記録できるようにします。 + `glue` – プリンシパルが AWS Glue Data Catalog テーブルに対して特定の書き込みアクションを実行できるようにします。これにより、 AWS Glue クローラはデータ内のパーティションを識別することもできます。 + `sqs` – プリンシパルが Amazon SQS キューに対して特定の読み取りおよび書き込みアクションを実行し、データレイクでオブジェクトが追加または更新されたときにイベント通知を送信できるようにします。 + `s3` – プリンシパルがデータを含む Amazon S3 バケットに対して特定の読み取りおよび書き込みアクションを実行できるようにします。 このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンスガイド*」の[AmazonSecurityLakeMetastoreManager](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSecurityLakeMetastoreManager.html)」を参照してください。 ## AWS マネージドポリシー: AmazonSecurityLakePermissionsBoundary Amazon Security Lake は、サードパーティのカスタムソースがデータレイクにデータを書き込むためのものと、サードパーティのカスタムサブスクライバーがデータレイクからデータを消費するための IAM ロールを作成し、その際にこのポリシーを使用して権限の境界を定義します。このポリシーを使用するために、お客様が実行する必要があるアクションはありません。データレイクがカスタマーマネージド AWS KMS キーで暗号化されている場合、 `kms:Decrypt` アクセス`kms:GenerateDataKey`許可が追加されます。 このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンスガイド*」の[AmazonSecurityLakePermissionsBoundary](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSecurityLakePermissionsBoundary.html)」を参照してください。 ## AWS マネージドポリシー: AmazonSecurityLakeAdministrator アカウントで Amazon Security Lake を有効にする前に、プリンシパルに `AmazonSecurityLakeAdministrator` ポリシーをアタッチできます。このポリシーにより、プリンシパルが Security Lake のすべてのアクションに完全にアクセスすることが許可される、管理者許可が付与されます。その後、プリンシパルは Security Lake にオンボーディングし、Security Lake でソースとサブスクライバーを設定できます。 このポリシーには、Security Lake 管理者が Security Lake を通じて他の AWS サービスに対して実行できるアクションが含まれています。 この`AmazonSecurityLakeAdministrator`ポリシーは、Security Lake が Amazon S3 クロスリージョンレプリケーションの管理、 での新しいデータパーティションの登録 AWS Glue、カスタムソースに追加されたデータに対する Glue クローラの実行、または新しいデータの HTTPS エンドポイントサブスクライバーへの通知に必要なユーティリティロールの作成をサポートしていません。これらのロールは、「[Amazon Security Lake の開始方法](getting-started.md)」で説明されているように事前に作成できます。 `AmazonSecurityLakeAdministrator` 管理ポリシーに加えて、Security Lake にはオンボーディングと設定機能のための `lakeformation:PutDataLakeSettings` 権限が必要です。`PutDataLakeSettings` は、アカウント内のすべてのリージョンの Lake Formation リソースの管理者として IAM プリンシパルを設定できます。このロールには `iam:CreateRole permission` と `AmazonSecurityLakeAdministrator` のポリシーが添付されている必要があります。 Lake Formation 管理者は Lake Formation コンソールへのフルアクセス権を持ち、初期データ設定とアクセス権限を制御できます。Security Lake は、Security Lake を有効にするプリンシパルと `AmazonSecurityLakeMetaStoreManager` ロール (またはその他の指定されたロール) を Lake Formation 管理者として割り当てます。これにより、管理者はテーブルの作成、テーブルスキーマの更新、新しいパーティションの登録、テーブルに対する権限の設定を行うことができます。Security Lake 管理者ユーザーまたはロールのポリシーには、次のアクセス許可を含める必要があります。 **注記** Lake Formation ベースのサブスクライバーアクセスを許可するのに十分なアクセス許可を提供するために、Security Lake では次のアクセス`glue:PutResourcePolicy`許可を追加することをお勧めします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowPutLakeFormationSettings", "Effect": "Allow", "Action": "lakeformation:PutDatalakeSettings", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": "securitylake.amazonaws.com" } } }, { "Sid": "AllowGlueActions", "Effect": "Allow", "Action": ["glue:PutResourcePolicy", "glue:DeleteResourcePolicy"], "Resource": [ "arn:aws:glue:*:*:catalog", "arn:aws:glue:*:*:database/amazon_security_lake_glue_db*", "arn:aws:glue:*:*:table/amazon_security_lake_glue_db*/*" ], "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": "securitylake.amazonaws.com" } } } ] } ``` ------ **アクセス許可の詳細** このポリシーには、以下のアクセス許可が含まれています。 + `securitylake` - すべての Security Lakeアクションへの完全なアクセスをプリンシパルに許可します。 + `organizations` – プリンシパルが AWS Organizations から組織内のアカウントに関する情報を取得できるようにします。アカウントが組織に属している場合、これらの許可は、Security Lake コンソールがアカウント名とアカウント番号を表示することを許可します。 + `iam` – プリンシパルが Security Lake、 AWS Lake Formation、および のサービスにリンクされたロールを Amazon EventBridge、これらのサービスを有効にするために必要なステップとして作成できるようにします。また、サブスクライバーロールとカスタムソースロールのポリシーを作成および編集できます。これらのロールの権限は、`AmazonSecurityLakePermissionsBoundary` ポリシーで許可されているものに限定されます。 + `ram` – Security Lake ソースへのサブスクライバーによる設定 Lake Formationベースのクエリアクセスをプリンシパルに許可します。 + `s3` — プリンシパルが Security Lake バケットを作成および管理し、それらのバケットの内容を読み取ることを許可します。 + `lambda` – プリンシパルが、 AWS ソース配信とクロスリージョンレプリケーション後にテーブルパーティションを更新する Lambda AWS Glue ために使用される を管理できるようにします。 + `glue` — プリンシパルが Security Lake のデータベースとテーブルを作成および管理できるようにします。 + `lakeformation` – プリンシパルが Security Lake テーブルの Lake Formation アクセス許可を管理できるようにします。 + `events` — プリンシパルが Security Lake ソース内の新しいデータをサブスクライバーに通知するためのルールを管理できるようにします。 + `sqs` – Security Lake ソースの新しいデータをサブスクライバーに通知するために使用される Amazon SQS キューを作成および管理することをプリンシパルに許可します。 + `kms` — プリンシパルが Security Lake に顧客管理キーを使用してデータを書き込むためのアクセス権を付与できるようにします。 + `secretsmanager` — プリンシパルが HTTPS エンドポイント経由で、Security Lake ソース内の新しいデータをサブスクライバーに通知するために使用されるシークレットを管理できるようにします。 このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンスガイド*」の[AmazonSecurityLakeAdministrator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSecurityLakeAdministrator.html)」を参照してください。 ## AWS マネージドポリシー: SecurityLakeServiceLinkedRole Security Lake は、 という名前のサービスにリンクされたロール`AWSServiceRoleForSecurityLake`を使用して、セキュリティデータレイクを作成および運用します。 `SecurityLakeServiceLinkedRole` マネージド ポリシーを IAM エンティティにアタッチすることはできません。このポリシーは、ユーザーに代わって Security Lake がアクションを実行することを許可するサービスリンクロールに添付されます。詳細については、[「Security Lake のサービスにリンクされたロールのアクセス許可](https://docs.aws.amazon.com//security-lake/latest/userguide/slr-permissions.html)」を参照してください。 ## AWS マネージドポリシー: SecurityLakeResourceManagementServiceRolePolicy Security Lake は、 という名前のサービスにリンクされたロール`AWSServiceRoleForSecurityLakeResourceManagement`を使用して継続的なモニタリングとパフォーマンスの向上を実行し、レイテンシーとコストを削減できます。Security Lake によって作成されたリソースを管理するためのアクセスを提供します。Security Lake に SecurityLake\$1Glue\$1Partition\$1Updater\$1Lambda を削除する機能を付与します。この Lambda は、iceberg 移行を実行し、v2 ソースに移行したお客様向けに廃止されました。この Lambda は、12 月に廃止される Python 3.9 ランタイムを使用していました。これらのお客様のためにこの Lambda のランタイムを更新するのではなく、削除することをお勧めします。Lambda をまだ必要としているかどうかを判断し、必要としていない場合は削除する復旧プロセスがあります。この SLR 更新は、その Lambda を削除できるようにするために必要です。 `SecurityLakeResourceManagementServiceRolePolicy` マネージド ポリシーを IAM エンティティにアタッチすることはできません。このポリシーは、ユーザーに代わって Security Lake がアクションを実行することを許可するサービスリンクロールに添付されます。詳細については、[「リソース管理のためのサービスにリンクされたロールのアクセス許可](https://docs.aws.amazon.com//security-lake/latest/userguide/AWSServiceRoleForSecurityLakeResourceManagement.html)」を参照してください。 **アクセス許可の詳細** このポリシーには、以下のアクセス許可が含まれています。 + `events` – プリンシパルが Security Lake イベント処理の EventBridge ルールを一覧表示および管理できるようにします。 + `lambda` – プリンシパルが、廃止されたパーティションアップデーター関数を削除する機能など、Security Lake メタデータ処理の Lambda 関数と設定を管理できるようにします。 + `glue` – プリンシパルが Security Lake メタデータ管理用の AWS Glue Data Catalog でパーティションの作成、テーブルの管理、データベースへのアクセスを許可します。 + `s3` – プリンシパルが Security Lake データレイクオペレーションの Amazon S3 バケット設定、ライフサイクルポリシー、メタデータオブジェクトを管理できるようにします。 + `logs` – プリンシパルが CloudWatch Logs ストリームにアクセスし、Security Lake Lambda 関数のログデータをクエリできるようにします。 + `sqs` – プリンシパルが Security Lake データ処理ワークフローの Amazon SQS キューとメッセージを管理できるようにします。 + `lakeformation` – プリンシパルが Security Lake リソース管理のデータレイク設定とアクセス許可を取得できるようにします。 JSON ポリシードキュメントの最新バージョンなど、ポリシーの詳細については、「 *AWS マネージドポリシーリファレンスガイド*」の[SecurityLakeResourceManagementServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityLakeResourceManagementServiceRolePolicy.html)」を参照してください。 ## AWS マネージドポリシー: AWS GlueServiceRole `AWS GlueServiceRole` 管理ポリシーは AWS Glue クローラを呼び出し、カスタムソースデータのクロールとパーティションメタデータの識別 AWS Glue を に許可します。このメタデータはデータカタログでテーブルを作成および更新するために必要です。 詳細については、「[Security Lake のカスタムソースからデータを収集する](custom-sources.md)」を参照してください。 ## AWS マネージドポリシーに対する Security Lake の更新 このサービスがこれらの変更の追跡を開始してからの Security Lake の AWS マネージドポリシーの更新に関する詳細を表示します。このページの変更に関する自動通知については、Security Lake の [Document history] (ドキュメントの履歴) ページの RSS フィードをサブスクライブしてください。 | 変更 | 説明 | 日付 | | --- | --- | --- | | [SecurityLakeResourceManagementServiceRolePolicy](#security-iam-awsmanpol-SecurityLakeServiceLinkedRole-ResourceManagement) – 既存のポリシーを更新しました | Security Lake は、管理ポリシーを更新`SecurityLakeResourceManagementServiceRolePolicy`して、廃止された SecurityLake\$1Glue\$1Partition\$1Updater\$1Lambda 関数の`lambda:DeleteFunction`アクセス許可を追加しました。これにより、Security Lake は v2 ソースと iceberg 形式への移行の一環として、非推奨の Lambda 関数をクリーンアップできます。 | 2025 年 11 月 18 日 | | [AWSServiceRoleForSecurityLakeResourceManagement](AWSServiceRoleForSecurityLakeResourceManagement.md) – 既存のポリシーを更新 | このポリシーは、 `StringLike`演算子を `ArnLike`演算子に置き換えて、 `aws:ResourceAccount` 条件ブロック`lambda:FunctionArn`の の ARN タイプのキーを評価するように更新されました。これにより、より安全な適用が可能になります。 | 2025 年 9 月 25 日 | | [Amazon Security Lake のサービスにリンクされたロール](AWSServiceRoleForSecurityLakeResourceManagement.md) – 新しいサービスにリンクされたロール | 新しいサービスにリンクされたロール を追加しました`AWSServiceRoleForSecurityLakeResourceManagement`。このサービスにリンクされたロールは、Security Lake が継続的なモニタリングとパフォーマンスの向上を実行するアクセス許可を提供するため、レイテンシーとコストを削減できます。 | 2024 年 11 月 14 日 | | [Amazon Security Lake のサービスにリンクされたロール](using-service-linked-roles.md) – 既存のサービスにリンクされたロールのアクセス許可の更新 | `SecurityLakeServiceLinkedRole` ポリシーの AWS マネージドポリシーに AWS WAF アクションを追加しました。追加のアクションにより、Security Lake で AWS WAF ログソースとして有効になっている場合、Security Lake はログを収集できます。 | 2024 年 5 月 22 日 | | [AmazonSecurityLakePermissionsBoundary](#security-iam-awsmanpol-AmazonSecurityLakePermissionsBoundary) – 既存ポリシーへの更新 | Security Lake がポリシーに SID アクションを追加しました。 | 2024 年 5 月 13 日 | | [AmazonSecurityLakeMetastoreManager](#security-iam-awsmanpol-AmazonSecurityLakeMetastoreManager) – 既存ポリシーへの更新 | Security Lake は、データレイク内のメタデータを削除できるメタデータクリーンアップアクションを追加するようにポリシーを更新しました。 | 2024 年 3 月 27 日 | | [AmazonSecurityLakeAdministrator](#security-iam-awsmanpol-AmazonSecurityLakeAdministrator) – 既存ポリシーへの更新 | Security Lake は、新しい`AmazonSecurityLakeMetastoreManagerV2`ロール`iam:PassRole`で を許可するようにポリシーを更新し、Security Lake がデータレイクコンポーネントをデプロイまたは更新できるようにします。 | 2024 年 2 月 23 日 | | [AmazonSecurityLakeMetastoreManager](#security-iam-awsmanpol-AmazonSecurityLakeMetastoreManager) - 新しいポリシー | Security Lake は、Security Lake がデータレイク内のメタデータを管理するためのアクセス許可を付与する新しい管理ポリシーを追加しました。 | 2024 年 1 月 23 日 | | [AmazonSecurityLakeAdministrator](#security-iam-awsmanpol-AmazonSecurityLakeAdministrator) - 新しいポリシー | Security Lake は、すべての Security Lake アクションへのフルアクセスをプリンシパルに付与する新しい管理ポリシーを追加しました。 | 2023 年 5 月 30 日 | | Security Lake が変更の追跡を開始 | Security Lake は、 AWS マネージドポリシーの変更の追跡を開始しました。 | 2022 年 11 月 29 日 | # Security Lake のサービスにリンクされたロールの使用 Security Lake は AWS Identity and Access Management (IAM) [サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスにリンクされたロールは、Security Lake に直接リンクされた IAM ロールです。これは Security Lake によって事前定義されており、Security Lake がユーザーに代わって他の AWS のサービス を呼び出し、セキュリティ データ レイク サービスを操作するために必要なすべてのアクセス許可が含まれています。Security Lake は、Security Lake AWS リージョン が利用可能なすべての でこのサービスにリンクされたロールを使用します。 サービスリンクロールを使用することで、Security Lake の設定時に必要な許可を手動で追加する必要がなくなります。Security Lake は、サービスリンクロールの許可を定義します。その許可が特別に定義されていない限り、Security Lake のみがそのロールを引き受けます。定義された許可には信頼ポリシーと許可ポリシーが含まれ、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。 サービスリンクロールの作成、編集、削除をIAM エンティティ (ユーザー、グループ、ロールなど) に許可するには、許可を設定する必要があります。詳細については、*「IAM User Guide」*(IAM ユーザーガイド) の[「Service-linked role permissions」](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)(サービスリンクロールのアクセス権限) を参照してください。サービスリンクロールを削除するには、その関連リソースを削除します。これにより、リソースへの意図しないアクセスによる権限の削除が防止され、 リソースは保護されます。 サービスにリンクされたロールをサポートする他のサービスの詳細については、[AWS 「IAM と連携するサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、「サービス**にリンクされたロール**」列で**「はい**」があるサービスを探します。サービスリンクロールに関するドキュメントをサービスで表示するには、**[Yes]** (はい) リンクを選択します。 **Topics** + [Security Lake のサービスにリンクされたロール (SLR) アクセス許可](slr-permissions.md) + [リソース管理のためのサービスリンクロール (SLR) アクセス許可](AWSServiceRoleForSecurityLakeResourceManagement.md) # Security Lake のサービスにリンクされたロール (SLR) アクセス許可 Security Lake では、`AWSServiceRoleForSecurityLake` という名前のサービスリンクロールを使用します。このサービスリンクロールは、ロールを引き受ける上で `securitylake.amazonaws.com` サービスを信頼します。Amazon Security Lake AWS の管理ポリシーの詳細については、[AWS 「Amazon Security Lake の管理ポリシー](https://docs.aws.amazon.com//security-lake/latest/userguide/security-iam-awsmanpol.html)」を参照してください。 という名前の AWS マネージドポリシーであるロールのアクセス許可ポリシー`SecurityLakeServiceLinkedRole`により、Security Lake はセキュリティデータレイクを作成して運用できます。また、Security Lake は指定されたリソースに対して次のようなタスクを実行できるようになります。 + AWS Organizations アクションを使用して、関連付けられたアカウントに関する情報を取得する + Amazon Elastic Compute Cloud (Amazon EC2) を使用して、Amazon VPC フローログに関する情報を取得します + AWS CloudTrail アクションを使用して、サービスにリンクされたロールに関する情報を取得する + Security Lake で AWS WAF ログソースとして有効になっている場合、 AWS WAF アクションを使用してログを収集する + `LogDelivery` アクションを使用して、 AWS WAF ログ配信サブスクリプションを作成または削除します。 このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンスガイド*」の[SecurityLakeServiceLinkedRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityLakeServiceLinkedRole.html)」を参照してください。 サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については、*「IAM User Guide」*(IAM ユーザーガイド) の[「Service-linked role permissions」](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)(サービスリンクロールのアクセス権限) を参照してください。 ## Security Lake のサービスリンクロールの作成 Security Lake 用の`AWSServiceRoleForSecurityLake`サービスリンクロールを手動で作成する必要はありません。で Security Lake を有効にすると AWS アカウント、Security Lake は自動的にサービスにリンクされたロールを作成します。 ## Security Lake 向けのサービスリンクロールの編集 Security Lake では、`AWSServiceRoleForSecurityLake` サービスリンクロールの編集は許可されていません。サービスリンクロールを作成すると、多くのエンティティによってロールが参照される可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」の「*サービスリンクロールの編集*」を参照してください。 ## Security Lake 向けのサービスリンクロールの削除 サービスリンクロールを Security Lake から削除することはできません。代わりに、IAM コンソール、API、または からサービスにリンクされたロールを削除できます AWS CLI。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。 サービスリンクロールを削除する前に、まずロールにアクティブなセッションがないことを確認し、`AWSServiceRoleForSecurityLake` が使用しているリソースを削除する必要があります。 **注記** リソースを削除しようとするときに Security Lake が `AWSServiceRoleForSecurityLake` ロールを使用している場合、削除は失敗する可能性があります。失敗した場合は、数分待ってから操作を再試行してください。 `AWSServiceRoleForSecurityLake`サービスリンクロールを削除したが、再作成する必要がある場合は、アカウントで Security Lake を有効にすることで、ロールを再作成することができます。Security Lake を再作成すると、Security Lake は、ユーザーのためにサービスリンクロールを再作成します。 ## Security Lake サービスにリンクされたロール AWS リージョン でサポート Security Lake は、Security Lake AWS リージョン が利用可能なすべての で`AWSServiceRoleForSecurityLake`サービスにリンクされたロールの使用をサポートしています。Security Lake が現在利用可能なリージョンのリストについては、「[Security Lake のリージョンとエンドポイント](supported-regions.md)」を参照してください。 # リソース管理のためのサービスリンクロール (SLR) アクセス許可 Security Lake は、 という名前のサービスにリンクされたロール`AWSServiceRoleForSecurityLakeResourceManagement`を使用して、継続的なモニタリングとパフォーマンスの向上を実行します。これにより、レイテンシーとコストを削減できます。このサービスリンクロールは、ロールを引き受ける上で `resource-management.securitylake.amazonaws.com` サービスを信頼します。また`AWSServiceRoleForSecurityLakeResourceManagement`、 を有効にすると、Lake Formation へのアクセスが許可され、セキュリティを強化するために、すべてのリージョンで Security Lake マネージド S3 バケットを Lake Formation に自動的に登録します。 という名前の AWS マネージドポリシーであるロールのアクセス許可ポリシーは`SecurityLakeResourceManagementServiceRolePolicy`、データレイク内のメタデータの管理など、Security Lake によって作成されたリソースを管理するためのアクセスを許可します。Amazon Security Lake AWS の管理ポリシーの詳細については、[AWS 「Amazon Security Lake の管理ポリシー](https://docs.aws.amazon.com//security-lake/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-SecurityLakeServiceLinkedRole-ResourceManagement.html)」を参照してください。 このサービスにリンクされたロールにより、Security Lake は、Security Lake (S3 Bucket、 AWS Glue tables、Amazon SQS Queue、Metastore Manager (MSM) Lambda Function、EventBridge ルール) によってアカウントにデプロイされたリソースのヘルスをモニタリングできます。Security Lake がこのサービスにリンクされたロールで実行できるオペレーションの例を次に示します。 + Apache Iceberg マニフェストファイルの圧縮により、クエリのパフォーマンスが向上し、Lambda MSM の処理時間とコストを削減できます。 + Amazon SQS の状態をモニタリングして、取り込みの問題を検出します。 + メタデータファイルを除外するために、クロスリージョンデータレプリケーションを最適化します。 **注記** `AWSServiceRoleForSecurityLakeResourceManagement` サービスにリンクされたロールをインストールしない場合、Security Lake は引き続き機能しますが、Security Lake がアカウントのリソースをモニタリングおよび最適化できるように、このサービスにリンクされたロールを受け入れることを強くお勧めします。 **アクセス許可の詳細** そのロールは、次のアクセス許可ポリシーで設定する必要があります。 + `events` – プリンシパルがログソースとログサブスクライバーに必要な EventBridge ルールを管理できるようにします。 + `lambda` – AWS プリンシパルがソース配信とクロスリージョンレプリケーション後に AWS Glue テーブルパーティションを更新するために使用される Lambda を管理できるようにします。 + `glue` – プリンシパルが AWS Glue Data Catalog テーブルに対して特定の書き込みアクションを実行できるようにします。これにより、 AWS Glue クローラはデータ内のパーティションを識別でき、Security Lake は Apache Iceberg テーブルの Apache Iceberg メタデータを管理できます。 + `s3` – プリンシパルが、ログデータと Glue テーブルメタデータを含む Security Lake バケットに対して特定の読み取りおよび書き込みアクションを実行できるようにします。 + `logs` – Lambda 関数の出力を CloudWatch Logs に記録するための読み取りアクセスをプリンシパルに許可します。 + `sqs` – プリンシパルが、データレイクでオブジェクトが追加または更新されたときにイベント通知を受け取る Amazon SQS キューに対して特定の読み取りおよび書き込みアクションを実行できるようにします。 + `lakeformation` – プリンシパルが Lake Formation 設定を読み取って設定ミスをモニタリングできるようにします。 このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンスガイド*」の[SecurityLakeResourceManagementServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityLakeResourceManagementServiceRolePolicy.html)」を参照してください。 サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については、*「IAM User Guide」*(IAM ユーザーガイド) の[「Service-linked role permissions」](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)(サービスリンクロールのアクセス権限) を参照してください。 ## Security Lake のサービスリンクロールの作成 Security Lake `AWSServiceRoleForSecurityLakeResourceManagement`のサービスにリンクされたロールは、Security Lake コンソールまたは を使用して作成できます AWS CLI。 サービスにリンクされたロールを作成するには、IAM ユーザーまたは IAM ロールに次のアクセス許可を付与する必要があります。IAM ロールは、Security Lake が有効なすべてのリージョンで Lake Formation 管理者である必要があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowLakeFormationActionsViaSecurityLakeConsole", "Effect": "Allow", "Action": [ "lakeformation:GrantPermissions", "lakeformation:ListPermissions", "lakeformation:ListResources", "lakeformation:RegisterResource", "lakeformation:RevokePermissions" ], "Resource": "*" }, { "Sid": "AllowIamActionsViaSecurityLakeConsole", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:GetPolicyVersion", "iam:GetRole", "iam:PutRolePolicy" ], "Resource": [ "arn:*:iam::*:role/aws-service-role/resource-management.securitylake.amazonaws.com/AWSServiceRoleForSecurityLakeResourceManagement", "arn:*:iam::*:role/*AWSServiceRoleForLakeFormationDataAccess", "arn:*:iam::aws:policy/service-role/AWSGlueServiceRole", "arn:*:iam::aws:policy/service-role/AmazonSecurityLakeMetastoreManager", "arn:*:iam::aws:policy/aws-service-role/SecurityLakeResourceManagementServiceRolePolicy" ], "Condition": { "StringLikeIfExists": { "iam:AWSServiceName": [ "securitylake.amazonaws.com", "resource-management.securitylake.amazonaws.com", "lakeformation.amazonaws.com" ] } } }, { "Sid": "AllowGlueActionsViaConsole", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetTables" ], "Resource": [ "arn:*:glue:*:*:catalog", "arn:*:glue:*:*:database/amazon_security_lake_glue_db*", "arn:*:glue:*:*:table/amazon_security_lake_glue_db*/*" ] } ] } ``` ------ ------ #### [ Console ] 1. Security Lake コンソール [https://console.aws.amazon.com/securitylake/](https://console.aws.amazon.com/securitylake/) を開きます。 1. 概要ページの情報バーでサービスにリンクされたロール**を有効にするをクリックして、新しいサービスにリンクされたロール**を受け入れます。 サービスにリンクされたロールを有効にすると、Security Lake を将来使用するためにこのプロセスを繰り返す必要はありません。 ------ #### [ CLI ] `AWSServiceRoleForSecurityLakeResourceManagement` サービスにリンクされたロールをプログラムで作成するには、次の CLI コマンドを使用します。 ``` $ aws iam create-service-linked-role --aws-service-name resource-management.securitylake.amazonaws.com ``` を使用して`AWSServiceRoleForSecurityLakeResourceManagement`サービスにリンクされたロールを作成するときは AWS CLI、テーブルメタデータを管理し、データにアクセスするために、Security Lake Glue データベース上のすべてのテーブルに Lake Formation テーブルレベルのアクセス許可 (ALTER、DESCRIBE) も付与する必要があります。いずれかのリージョンの Glue テーブルが以前の Security Lake 有効化の S3 バケットを参照する場合は、サービスにリンクされたロールへの DATA\$1LOCATION\$1ACCESS アクセス許可を一時的に許可して、Security Lake がこの状況を修復できるようにする必要があります。 また、Lake Formation のアクセス許可をアカウントの`AWSServiceRoleForSecurityLakeResourceManagement`サービスにリンクされたロールに付与する必要があります。 次の例は、指定されたリージョンのサービスにリンクされたロールに Lake Formation のアクセス許可を付与する方法を示しています。この例は Linux、macOS、または Unix 用にフォーマットされており、読みやすさを向上させるためにバックスラッシュ (\$1) の行継続文字を使用しています。 ``` $ aws lakeformation grant-permissions --region {region} --principal DataLakePrincipalIdentifier={AWSServiceRoleForSecurityLakeResourceManagement ARN} \ --permissions ALTER DESCRIBE --resource '{ "Table": { "DatabaseName": "amazon_security_lake_glue_db_{region}", "TableWildcard": {} } }' ``` 次の例は、ロール ARN がどのように表示されるかを示しています。リージョンと一致するようにロール ARN を編集する必要があります。 `"AWS": "arn:[partition]:iam::[accountid]:role/aws-service-role/resource-management.securitylake.amazonaws.com/AWSServiceRoleForSecurityLakeResourceManagement"` [CreateServiceLinkedRole](https://docs.aws.amazon.com//IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API コールを使用することもできます。リクエストで、 を `AWSServiceName`として指定します`resource-management.securitylake.amazonaws.com`。 ------ `AWSServiceRoleForSecurityLakeResourceManagement` ロールを有効にした後、暗号化に AWS KMS カスタマーマネージドキー (CMK) を使用している場合は、サービスにリンクされたロールが CMK が存在するリージョンの S3 バケットに暗号化されたオブジェクトを AWS 書き込むことを許可する必要があります。 AWS KMS コンソールで、CMK が存在する AWS リージョンの KMS キーに次のポリシーを追加します。KMS キーポリシーを変更する方法の詳細については、 AWS Key Management Service デベロッパーガイドの「 [のキーポリシー AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policies.html)」を参照してください。 ``` { "Sid": "Allow SLR", "Effect": "Allow", "Principal": { "AWS": "arn:[partition]:iam::[accountid]:role/aws-service-role/resource-management.securitylake.amazonaws.com/AWSServiceRoleForSecurityLakeResourceManagement" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "*", "Condition": { "StringEquals": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::[regional-datalake-s3-bucket-name]" }, "StringLike": { "kms:ViaService": "s3.[region].amazonaws.com" } } }, ``` ## Security Lake 向けのサービスリンクロールの編集 Security Lake では、`AWSServiceRoleForSecurityLakeResourceManagement` サービスリンクロールの編集は許可されていません。サービスリンクロールを作成すると、多くのエンティティによってロールが参照される可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」の「*サービスリンクロールの編集*」を参照してください。 ## Security Lake 向けのサービスリンクロールの削除 サービスリンクロールを Security Lake から削除することはできません。代わりに、IAM コンソール、API、または からサービスにリンクされたロールを削除できます AWS CLI。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。 サービスリンクロールを削除する前に、まずロールにアクティブなセッションがないことを確認し、`AWSServiceRoleForSecurityLakeResourceManagement` が使用しているリソースを削除する必要があります。 **注記** リソースを削除しようとするときに Security Lake が `AWSServiceRoleForSecurityLakeResourceManagement` ロールを使用している場合、削除は失敗する可能性があります。失敗した場合は、数分待ってから操作を再試行してください。 `AWSServiceRoleForSecurityLakeResourceManagement`サービスリンクロールを削除したが、再作成する必要がある場合は、アカウントで Security Lake を有効にすることで、ロールを再作成することができます。Security Lake を再作成すると、Security Lake は、ユーザーのためにサービスリンクロールを再作成します。 ## Security Lake サービスにリンクされたロール AWS リージョン でサポート Security Lake は、Security Lake AWS リージョン が利用可能なすべての で`AWSServiceRoleForSecurityLakeResourceManagement`サービスにリンクされたロールの使用をサポートしています。Security Lake が現在利用可能なリージョンのリストについては、「[Security Lake のリージョンとエンドポイント](supported-regions.md)」を参照してください。 # Amazon Security Lake におけるデータ保護 責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、Amazon Security Lake でのデータ保護に適用されます。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された [AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) のブログ記事を参照してください。 データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします: + 各アカウントで多要素認証 (MFA) を使用します。 + SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 が必須で、TLS 1.3 をお勧めします。 + で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。 + AWS 暗号化ソリューションと、その中のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。 + Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。 + コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。 お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール、API、または SDK を使用して Security Lake AWS CLIまたは他の AWS のサービス を使用する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。 ## 保管中の暗号化 Amazon Security Lake は、 AWS 暗号化ソリューションを使用して保管中のデータを安全に保存します。Raw セキュリティログとイベントデータは、Security Lake が管理するアカウントのソース固有の[マルチテナント Amazon Simple Storage Service (Amazon S3) バケット](https://docs.aws.amazon.com/AmazonS3/latest/userguide/common-bucket-patterns.html#multi-tenant-buckets)に保存されます。各ログソースには、独自のマルチテナントバケットがあります。Security Lake は、 AWS Key Management Service (AWS KMS) の [AWS 所有キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)を使用してこの raw データを暗号化します。 AWS 所有キーは、 AWS サービス、この場合は Security Lake が複数の AWS アカウントで使用するために所有および管理する AWS KMS キーのコレクションです。 Security Lake は、生のログとイベントデータに対して抽出、変換、ロード (ETL) ジョブを実行します。 ETL ジョブが完了すると、Security Lake はアカウントにシングルテナント S3 バケットを作成します (Security Lake を有効に AWS リージョン したバケットごとに 1 つのバケット）。Security Lake がシングルテナント S3 バケットにデータを確実に配信できるようになるまで、データはマルチテナント S3 バケットに一時的にのみ保存されます。シングルテナントバケットには、ログとイベントデータをバケットに書き込む権限を Security Lake に付与するリソースベースのポリシーが含まれています。S3 バケット内のデータを暗号化するには、[S3-managed暗号化キー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html)または[カスタマーマネージドキー ](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (送信元) のいずれかを選択できます AWS KMS。どちらの方法も対称暗号化を使用します。 ### KMS キーを使用してデータを暗号化します。 デフォルトでは、Security Lake によって S3 バケットに配信されるデータは、[Amazon S3 で管理された暗号化キー (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) を使用した Amazon サーバー側の暗号化によって暗号化されます。直接管理するセキュリティレイヤーを提供するには、代わりに Security Lake データに[AWS KMS キーによるサーバー側の暗号化 (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) を使用できます。 SSE-KMS は、セキュリティレイクコンソールではサポートされていません。セキュリティレイク API または CLI で SSE-KMS を使用するには、まず [KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)か、既存のキーを使用します。Security Lake データの暗号化と復号化にどのユーザーがキーを使用できるかを決定するポリシーをキーにアタッチします。 顧客管理キーを使用して S3 バケットに書き込まれるデータを暗号化する場合、マルチリージョンキーは選択できません。カスタマー管理キーの場合、Security Lake は `CreateGrant` リクエストを AWS KMSに送信することで、ユーザーに代わって[許可](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)を作成します。の権限 AWS KMS は、Security Lake に顧客アカウントの KMS キーへのアクセスを許可するために使用されます。 Security Lake では、次の内部操作に顧客管理キーを使用するための許可を必要とします。 + カスタマーマネージドキーによって暗号化されたデータキーを生成する AWS KMS リクエスト`GenerateDataKey`を に送信します。 + `RetireGrant` リクエストの送信先 AWS KMS。データレイクを更新すると、この操作により、ETL 処理用の AWS KMS キーに追加されたグラントの廃止が可能になります。 セキュリティレイクには`Decrypt`権限は必要ありません。キーの許可されたユーザーが Security Lake データを読み取ると、S3 が復号化を管理し、許可されたユーザーは暗号化されていない形式でデータを読み取ることができます。ただし、サブスクライバーがソースデータを使用するには`Decrypt`権限が必要です。サブスクライバー権限の詳細については、[Security Lake サブスクライバーのデータアクセスの管理](subscriber-data-access.md) を参照してください。 既存の KMS キーを使用して Security Lake データを暗号化する場合は、KMS キーのキーポリシーを変更する必要があります。キーポリシーでは、Lake Formation データレイクの場所に関連付けられた IAM ロールが KMS キーを使用してデータを復号できるようにする必要があります。KMS キーのキーポリシーを変更する方法については、「 AWS Key Management Service デベロッパーガイド」の[「キーポリシーの変更](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying.html)」を参照してください。 キーポリシーを作成したり、適切な権限を持つ既存のキーポリシーを使用したりすると、KMS キーは付与リクエストを受け付けることができ、Security Lake がキーにアクセスできるようになります。キー ポリシーの作成手順については、*AWS Key Management Service 開発者ガイド*の[キー ポリシーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html)を参照してください。 次のキーポリシーを KMS キーにアタッチします。 ``` { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"}, "Action": [ "kms:CreateGrant", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": "*" } ``` ### 顧客マネージドキーを使用する場合に必要な IAM アクセス許可 Security Lake を使用するために作成する必要がある IAM ロールの概要については、「[はじめに:前提条件](get-started-programmatic.md#prerequisites)」セクションを参照してください。 カスタムソースまたはサブスクライバーを追加すると、Security Lake はアカウントに IAM ロールを作成します。これらのロールは他の IAM ID と共有することを目的としています。これにより、カスタムソースはデータレイクにデータを書き込み、サブスクライバーはデータレイクからのデータを使用できます。という AWS マネージドポリシーは、これらのロールのアクセス許可の境界`AmazonSecurityLakePermissionsBoundary`を設定します。 ### Amazon SQS キューの暗号化 データレイクを作成すると、Security Lake は委任されたセキュリティレイク管理者アカウントに 2 つの暗号化されていない Amazon Simple Queue Service (Amazon SQS) キューを作成します。データを保護するには、これらのキューを暗号化する必要があります。Amazon Simple Queue Service が提供するデフォルトのサーバー側の暗号化では十分ではありません。( AWS Key Management Service AWS KMS) でカスタマーマネージドキーを作成してキューを暗号化し、暗号化されたキューを操作するためのアクセス許可を Amazon S3 サービスプリンシパルに付与する必要があります。これらのアクセス許可を付与する手順については、 AWS ナレッジセンターの[Amazon S3イベント通知がサーバー側の暗号化を使用する Amazon SQS キューに配信されないのはなぜですか?](https://repost.aws/knowledge-center/sqs-s3-event-notification-sse)」を参照してください。 Security Lake は AWS Lambda を使用してデータの抽出、転送、ロード (ETL) ジョブをサポートするため、Amazon SQS キュー内のメッセージを管理するための Lambda アクセス許可も付与する必要があります。詳細については、「*AWS Lambda デベロッパーガイド*」の「[実行ロールのアクセス許可](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-permissions)」を参照してください。 ## 転送中の暗号化 Security Lake は、 AWS サービス間で転送中のすべてのデータを暗号化します。Security Lake は、トランスポート層セキュリティ (TLS) 1.2 暗号化プロトコルを使用してすべてのネットワーク間データを自動的に暗号化することにより、サービスとの間で送受信されるデータを保護します。Security Lake API に送信されるダイレクト HTTPS リクエストは、[署名バージョン 4 AWS アルゴリズムを使用して署名され](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)、安全な接続を確立します。 # サービス改善のためのデータ使用をオプトアウトする オプトアウトポリシーを使用して、Security Lake およびその他の AWS セキュリティサービスの開発と改善にデータを使用することを AWS Organizations オプトアウトできます。Security Lake が現在そのようなデータを収集していない場合でも、オプトアウトすることができます。オプトアウトする方法の詳細については、「*AWS Organizations ユーザーガイド*」の「[AI サービスのオプトアウトポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html)」を参照してください。 現在、Security Lake は、ユーザーに代わって処理するセキュリティデータや、このサービスによって作成されたセキュリティデータレイクにユーザーがアップロードしたセキュリティデータを収集することはありません。Security Lake サービスおよび他の AWS セキュリティサービスの機能を開発および改善するために、Security Lake は、サードパーティーのデータソースからアップロードしたデータを含め、将来そのようなデータを収集することがあります。Security Lake がそのようなデータを収集する予定がある場合は、このページを更新し、その仕組みについて説明します。ただし、いつでもオプトアウトすることができます。 **注記** オプトアウトポリシーを使用するには、 AWS アカウントが によって一元管理されている必要があります AWS Organizations。 AWS アカウントの組織をまだ作成していない場合は、*AWS Organizations 「 ユーザーガイド*」の[「組織の作成と管理](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org.html)」を参照してください。 オプトアウトには次のような効果があります。 + Security Lake は、オプトアウト前に収集して保存したデータ (ある場合のみ) を削除します。 + オプトアウトすると、Security Lake はこのデータを収集または保存しません。 # Amazon SECURITY Lake のコンプライアンス検証 AWS のサービス が特定のコンプライアンスプログラムの範囲内にあるかどうかを確認するには、「コンプライアンス[AWS のサービス プログラムによる対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)」の「コンプライアンス」を参照して、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。 を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。 を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。 # Security Lake のセキュリティのベストプラクティス Amazon Security Lake を使用するには、次のベストプラクティスを確認します。 ## Security Lake ユーザーへの最小限のアクセス許可の付与 最小権限の原則に従い、 AWS Identity and Access Management (IAM) ユーザー、ユーザーグループ、ロールに最小限のアクセスポリシーアクセス許可を付与します。たとえば、IAM ユーザーに Security Lake のログソースのリストの表示を許可するが、ソースやサブスクライバーの作成は許可しない場合があります。詳細については、[Security Lake のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)を参照してください。 AWS CloudTrail を使用して Security Lake の API 使用状況を追跡することもできます。CloudTrail は、Security Lake のユーザー、グループ、またはロールによって実行された API アクションの記録を提供します。詳細については、「[CloudTrail を使用した Security Lake API コールのログ記録](securitylake-cloudtrail.md)」を参照してください。 ## 概要ページを表示します。 Security Lake コンソールの**概要**ページには、Security Lake サービスとデータが保存されている Amazon S3 バケットに影響を与えている過去 14 日間の問題の概要が表示されます。これらの問題をさらに調査して、起こり得るセキュリティ関連の影響を軽減するのに役立ちます。 ## Security Hub CSPM との統合 Security Lake と を統合し AWS Security Hub CSPM て、Security Lake で Security Hub CSPM の検出結果を受け取ります。Security Hub CSPM は、さまざまな AWS のサービス およびサードパーティーの統合から検出結果を生成します。Security Hub CSPM の検出結果を受け取ると、コンプライアンス体制の概要と、 AWS セキュリティのベストプラクティスを満たしているかどうかを把握できます。 詳細については、「[との統合 AWS Security Hub CSPM](securityhub-integration.md)」を参照してください。 ## 削除 AWS Lambda AWS Lambda 関数を削除するときは、最初に無効にしないことをお勧めします。削除する前に Lambda 関数を無効にすると、データクエリ機能が妨げられ、他の機能に影響を与える可能性があります。Lambda 関数は無効にせずに直接削除することをお勧めします。Lambda 関数の削除の詳細については、「 デ[AWS Lambda ベロッパーガイド](https://docs.aws.amazon.com//lambda/latest/dg/example_lambda_DeleteFunction_section.html)」を参照してください。 ## セキュリティレイクのイベントを監視してください。 Amazon CloudWatch メトリクスを使用してSecurity Lake をモニタリングできます。CloudWatch は、Security Lake から生データを毎分収集し、それをメトリクスに処理します。メトリックスが指定したしきい値に一致したときに通知をトリガーするアラームを設定できます。 詳細については、「[Amazon Security Lake の CloudWatch メトリクス](cloudwatch-metrics.md)」を参照してください。 # Amazon Security Lake の耐障害性 AWS グローバルインフラストラクチャは、 AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。 は、低レイテンシー、高スループット、および高度に冗長なネットワークで接続された、物理的に分離および分離された複数のアベイラビリティーゾーン AWS リージョン を提供します。これらのアベイラビリティーゾーンを利用すると、アプリケーションとデータベースを効率的に設計して運用できます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。 セキュリティレイクの可用性は、リージョンの可用性と結びついています。複数のアベイラビリティーゾーンに分散することで、サービスはどのアベイラビリティーゾーンでも障害に耐えることができます。 Security Lake データプレーンの可用性は、どのリージョンの可用性とも関係ありません。ただし、Security Lake コントロールプレーンの可用性は、米国東部 (バージニア北部) リージョンの可用性と密接に関係しています。 AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。 AWS グローバルインフラストラクチャである Security Lake に加えて、Amazon Simple Storage Service (Amazon S3) によってデータがバックアップされます。 には、データの耐障害性とバックアップのニーズをサポートするのに役立ついくつかの機能があります。 **ライフサイクル設定** ライフサイクル設定は、Amazon S3 がオブジェクトのグループに適用するアクションを定義するルールのセットです。ライフサイクル設定ルールを使用すると、オブジェクトのより安価なストレージクラスへの移行、アーカイブ、削除を Amazon S3 に指定できます。詳細については、*Amazon S3 ユーザーガイド*の「[ストレージのライフサイクルの管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)」をご参照ください。 **バージョニング** バージョニングとは、同じバケット内でオブジェクトの複数のバリアントを保持する手段です。バージョニングを使用して、Amazon S3 バケットに格納されたあらゆるオブジェクトのあらゆるバージョンを、格納、取得、復元することができます。バージョニングによって、意図しないユーザーアクションとアプリケーション障害から復旧できます。詳細については、*『Amazon S3 ユーザーガイド』*の[「S3 バケットでのバージョニングの使用」](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)を参照してください。 **ストレージクラス** Amazon S3 では、ワークロードの要件に応じて、幅広いストレージクラスが提供されています。S3 標準 — IA と S3 1 ゾーン – IA ストレージクラスは、月に約 1 回アクセスし、ミリ秒単位のアクセスが必要になるデータ用に設計されています。S3 Glacier インスタント検索ストレージクラスは、四半期に約 1 回アクセスするミリ秒のアクセスでアクセスされる長期間有効なアーカイブデータ用に設計されています。バックアップなど、即時アクセスを必要としないアーカイブデータについては、S3 Glacier Flexible Retrieval または S3 Glacier Deep Archive ストレージクラスを使用できます。詳細については、『*Amazon S3 ユーザーガイド*』の「[Amazon S3 ストレージクラスの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)」を参照してください。 # Amazon Security Lake のインフラストラクチャセキュリティ マネージドサービスである Amazon Security Lake は、 AWS グローバルネットワークセキュリティで保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して環境を AWS 設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。 AWS 公開された API コールを使用して、ネットワーク経由で Security Lake にアクセスします。クライアントは以下をサポートする必要があります。 + Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。 + DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。 # Security Lake での構成と脆弱性の分析 設定と IT コントロールは、 AWS とお客様の間で責任を共有します。詳細については、 AWS [「責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)」を参照してください。 # Amazon Security Lake とインターフェイス VPC エンドポイント (AWS PrivateLink) *インターフェイス VPC エンドポイント*を作成することで、VPC と Amazon Security Lake 間のプライベート接続を確立できます。インターフェイスエンドポイントは、インターネットゲートウェイ[AWS PrivateLink](https://aws.amazon.com/privatelink)、NAT デバイス、VPN 接続、または AWS Direct Connect 接続なしで Security Lake APIs にプライベートにアクセスできるテクノロジーである を利用しています。VPC 内のインスタンスは、Security Lake APIs と通信するためにパブリック IP アドレスを必要としません。VPC と Security Lake 間のトラフィックは Amazon ネットワークを離れません。 各インターフェイスエンドポイントは、サブネット内の 1 つ以上の [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) によって表されます。 詳細については、「AWS PrivateLink ガイド」の「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)」を参照してください。 ## Security Lake VPC エンドポイントに関する考慮事項 Security Lake のインターフェイス VPC エンドポイントを設定する前に、「 *AWS PrivateLink ガイド*」の[「インターフェイスエンドポイントのプロパティと制限](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations)」を確認してください。 Security Lake は、VPC からのすべての API アクションの呼び出しをサポートしています。 Security Lake は、FIPS が存在する次のリージョンでのみ FIPS VPC エンドポイントをサポートします。 + 米国東部 (バージニア北部) + 米国東部 (オハイオ) + 米国西部 (北カリフォルニア) + 米国西部 (オレゴン) ## Security Lake 用のインターフェイス VPC エンドポイントの作成 Security Lake サービスの VPC エンドポイントは、Amazon VPC コンソールまたは AWS Command Line Interface () を使用して作成できますAWS CLI。詳細については、「*AWS PrivateLink ガイド*」の「[インターフェイスエンドポイントを作成](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint)」を参照してください。 次のサービス名を使用して、Security Lake の VPC エンドポイントを作成します。 + com.amazonaws.*region*.securitylake + com.amazonaws.*region*.securitylake-fips (FIPS エンドポイント) エンドポイントのプライベート DNS を有効にすると、 などのリージョンのデフォルトの DNS 名を使用して Security Lake に API リクエストを行うことができます`securitylake.us-east-1.amazonaws.com`。 詳細については、AWS PrivateLink ガイドの[インターフェイスエンドポイントを介したサービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint)を参照してください。 ## Security Lake の VPC エンドポイントポリシーの作成 Security Lake へのアクセスを制御するエンドポイントポリシーを VPC エンドポイントにアタッチできます。このポリシーでは、以下の情報を指定します。 + アクションを実行できるプリンシパル。 + 実行可能なアクション。 + このアクションを実行できるリソース。 詳細については、「*AWS PrivateLink ガイド*」の「[Control access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」を参照してください。 **例: Security Lake アクションの VPC エンドポイントポリシー** 以下は、Security Lake のエンドポイントポリシーの例です。エンドポイントにアタッチすると、このポリシーは、すべてのリソースのすべてのプリンシパルに対して、リストされている Security Lake アクションへのアクセスを許可します。 ``` { "Statement":[ { "Principal":"*", "Effect":"Allow", "Action":[ "securitylake:ListDataLakes", "securitylake:ListLogSources", "securitylake:ListSubscribers" ], "Resource":"*" } ] } ``` ## 共有サブネット 自分と共有されているサブネットで VPC エンドポイントを作成、説明、変更、または削除することはできません。ただし、自分と共有されているサブネットでVPC エンドポイントを使用することはできます。VPC 共有の詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC を他のアカウントと共有する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)」を参照してください。 # Amazon Security Lakeのモニタリング Security Lake は と統合されています。これは AWS CloudTrail、ユーザー、ロール、または別の によって Security Lake で実行されたアクションを記録するサービスです AWS のサービス。これには、Security Lake コンソールからのアクションと、Security Lake API オペレーションへのプログラムによる呼び出しが含まれます。CloudTrail によって収集された情報を使用すると、どのリクエストが Security Lake に対して行われたかを判断できます。リクエストごとに、リクエスト日時、リクエスト元の IP アドレス、作成者、その他の詳細を確認できます。詳細については、「[CloudTrail を使用した Security Lake API コールのログ記録](securitylake-cloudtrail.md)」を参照してください。 Security Lake と Amazon CloudWatch は統合されているため、Security Lake が収集するログについてメトリクスを収集、表示、分析できます。Security Lake データレイクの CloudWatch メトリクスは自動的に収集され、1 分間隔で CloudWatch にプッシュされます。Security Lake メトリクスの指定のしきい値に達した場合に、通知が送信されるよう、アラームを設定することもできます。Security Lake が CloudWatch に送信するすべてのメトリクスのリストについては、「[Security Lake のメトリクスとディメンション](cloudwatch-metrics.md#available-securitylake-metrics)」を参照してください。 # Amazon Security Lake の CloudWatch メトリクス Amazon CloudWatch を使用して Security Lake を監視できます。Amazon CloudWatch は生データを毎分収集し、それを読み取り可能なほぼリアルタイムのメトリクスに処理します。これらの統計は 15 か月間保存されるため、履歴情報にアクセスして、データ レイク内のデータをより正確に把握できます。また、特定のしきい値を監視するアラームを設定し、これらのしきい値に達したときに通知を送信したりアクションを実行したりできます。 **Topics** + [Security Lake のメトリクスとディメンション](#available-securitylake-metrics) + [Security Lake の CloudWatch メトリクスの表示](#view-securitylake-metrics) + [Security Lake メトリクスの CloudWatch アラームの設定](#securitylake-alarm-metrics) ## Security Lake のメトリクスとディメンション `AWS/SecurityLake` 名前空間には、次のメトリクスが含まれます。 | メトリクス | 説明 | | --- | --- | | `ProcessedSize` | 現在データレイクに保存 AWS のサービス されている、ネイティブにサポートされている からのデータボリューム。 単位: バイト | Security Lakeメトリクス では以下のディメンションが利用可能です。 | ディメンション | 説明 | | --- | --- | | `Account` | 特定の AWS アカウントの `ProcessedSize` メトリクス。このディメンションは、CloudWatch で `Per-Account Source Version Metrics` を表示する場合にのみ使用できます。 | | `Region` | 特定の AWS リージョンの`ProcessedSize`メトリクス。 | | `Source` | `ProcessedSize` 特定の AWS ログソースの メトリクス。 | | `SourceVersion` | `ProcessedSize` 特定のバージョンの AWS ログソースの メトリクス。 | specific AWS アカウント (`Per-Account Source Version Metrics`) または組織内のすべてのアカウント () のメトリクスを表示できます`Per-Source Version Metrics`。 ## Security Lake の CloudWatch メトリクスの表示 Security Lake のメトリクスは、CloudWatch コンソール、CloudWatch 独自のコマンドラインインターフェイス (CLI) を使用するか、CloudWatch API を使用してプログラムで監視できます。ご希望の方法を選択し、手順に従って Security Lake メトリクスにアクセスします。 ------ #### [ CloudWatch console ] 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. ナビゲーションペインで、**[Metrics](メトリクス)、[All metrics] (すべてのメトリクス) **を選択します。 1. 「**ブラウズ**」タブで「**Security Lake**」を選択します。 1. [**アカウントごとのソースバージョンメトリクス**] または [**ソースバージョンごとのメトリクス**] を選択します。 1. メトリクスを選択して詳細を表示します。また、以下を実行することもできます。 + メトリクスを並べ替えるには、列見出しを使用します。 + メトリクスをグラフ表示するには、メトリクス名を選択し、グラフ表示オプションを選択します。 + メトリクスでフィルタするには、メトリクスの名前を選択し、[**Add to search**] を選択します。 ------ #### [ CloudWatch API ] CloudWatch APIを使用して Security Lakeメトリクスにアクセスするには、[https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html) アクションを使用します。 ------ #### [ AWS CLI ] を使用して Security Lake メトリクスにアクセスするには AWS CLI、 [https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-statistics.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-statistics.html) コマンドを実行します。 ------ CloudWatch メトリクスを使用したモニタリング方法の詳細については、*[Amazon CloudWatch ユーザーガイド]* の [[Amazon CloudWatch Metrics の使用]](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) を参照してください。 ## Security Lake メトリクスの CloudWatch アラームの設定 CloudWatch では、メトリクスのしきい値に到達したときのアラームを設定することもできます。たとえば、**ProcessedSize** メトリクスにアラームを設定して、特定のソースからのデータ量が特定のしきい値を超えたときに通知を受けることができます。 アラームの設定に関する詳細については、*Amazon CloudWatch ユーザーガイド*の「[Using Amazon CloudWatch Alarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。