翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Managed Workflows for Apache Airflow におけるセキュリティー
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
セキュリティは、 AWS とお客様 (顧客) が共有する責任です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウド*の*セキュリティおよびクラウド*内*のセキュリティと説明しています。
+ **クラウドのセキュリティ** – AWS クラウドで AWS サービスを実行するインフラストラクチャを保護する AWS 責任があります。 AWS また、 では、安全に使用できるサービスも提供しています。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。Amazon MWAA に適用されるコンプライアンスプログラムの詳細については、「コンプライアンスプログラム[AWS による対象範囲内のサービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、ユーザーは、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。
このドキュメントは、Amazon Managed Workflows for Apache Airflow 使用時における責任共有モデルの適用法を理解するのに役立ちます。これを使用して、セキュリティとコンプライアンスの目標を満たすように Amazon MWAA を設定します。また、Amazon MWAA リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [データ保護](data-protection.md)
+ [
# AWS Identity and Access Management
](security-iam.md)
+ [コンプライアンス検証](compliance-validation.md)
+ [耐障害性](disaster-recovery-resiliency.md)
+ [インフラストラクチャセキュリティ](infrastructure-security.md)
+ [設定と脆弱性の分析](configuration-vulnerability-analysis.md)
+ [ベストプラクティス](security-best-practices.md)
# Amazon Managed Workflows for Apache Airflow におけるデータ保護
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、Amazon Managed Workflows for Apache Airflow でのデータ保護に適用されます。このモデルで説明されているように、 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 Identity and Access Management IAM) を使用して AWS アカウント 認証情報を保護し、個々のユーザーアカウントを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要なアクセス許可のみを各ユーザーに付与できます。また、次の方法でデータを保護することをお勧めします。
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 以降が推奨されます。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。
+ AWS 暗号化ソリューションと、 サービス内のすべての AWS デフォルトのセキュリティコントロールを使用します。
+ Amazon Macie などのアドバンストマネージドセキュリティサービスを使用します。これは、Amazon S3 に保存されている個人データの検出と保護を支援します。
顧客の E メールアドレスなどの機密情報やセンシティブ情報は、タグや **名前** フィールドなどの自由形式のフィールドに配置しないことを強くお勧めします。これは、コンソール、API、または SDK を使用して Amazon MWAA AWS CLIまたは他の AWS のサービスを使用する場合も同様です。 AWS SDKs タグまたは名前に使用する自由記入欄に入力したデータは、課金や診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
# Amazon MWAA での暗号化
以下のトピックでは、Amazon MWAA が保管中および転送中のデータを保護する方法について説明します。この情報を使用して、Amazon MWAA が と統合 AWS KMS して保管中のデータを暗号化する方法と、転送中の Transport Layer Security (TLS) プロトコルを使用してデータを暗号化する方法について説明します。
**Topics**
+ [
## 保管中の暗号化
](#encryption-at-rest)
+ [
## 転送中の暗号化
](#encryption-in-transit)
## 保管中の暗号化
Amazon MWAA では、*保管中の* データとは、サービスが永続メディアに保存するデータです。
保管中のデータの暗号化には [AWS所有キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) を使用することも、環境の作成時にオプションで [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) を提供して追加の暗号化を行うこともできます。カスタマーマネージド KMS キーを使用する場合は、環境で使用している他の AWS リソースやサービスと同じアカウントに存在する必要があります。
カスタマーマネージド KMS キーを使用するには、CloudWatch アクセスに必要なポリシーステートメントをキーポリシーに添付する必要があります。お客様の環境でカスタマーマネージド KMS キーを使用する場合、Amazon MWAA はお客様に代わって 4 つの [許可](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) をアタッチします。Amazon MWAA がカスタマーマネージド KMS キーに付与する許可の詳細については、[データ暗号化用のカスタマーマネージドキー](custom-keys-certs.md) を参照してください。
カスタマー管理の KMS キーを指定しない場合、Amazon MWAA はデフォルトで の AWS 所有の KMS キーを使用してデータを暗号化および復号します。Amazon MWAA でデータ暗号化を管理するには、 AWS 所有の KMS キーを使用することをお勧めします。
**注記**
Amazon MWAA で AWS 所有またはカスタマー管理の KMS キーのストレージと使用に対して料金が発生します。詳細は、[AWS KMS 料金表](https://aws.amazon.com/kms/pricing/) を参照してください。
### 暗号化アーティファクト
Amazon MWAA 環境を作成するときに、[AWS所有キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) または [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) を指定して、保管時の暗号化に使用する暗号化アーティファクトを指定します。Amazon MWAA は、指定されたキーに必要な [許可](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) を追加します。
**[Amazon S3]** — Amazon S3 データは、サーバー側の暗号化 (SSE) を使用してオブジェクトレベルで暗号化されます。Amazon S3 の暗号化と復号化は、DAG コードとサポートファイルが保存される Amazon S3 バケットで行われます。オブジェクトは Amazon S3 にアップロードされるときに暗号化され、Amazon MWAA 環境にダウンロードされるときに復号化されます。デフォルトでは、カスタマー管理の KMS キーを使用している場合、Amazon MWAA はそのキーを使用して Amazon S3 バケットのデータを読み取り、復号化します。
**CloudWatch Logs** – AWS 所有の KMS キーを使用している場合、CloudWatch Logs に送信される Apache Airflow ログは、CloudWatch Logs AWS 所有の KMS キーで SSE を使用して暗号化されます。カスタマー管理の KMS キーを使用している場合は、CloudWatch Logs がキーを使用できるように、[キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) を KMS キーに追加する必要があります。
**Amazon SQS** — Amazon MWAA は、お使いの環境用に 1 つの Amazon SQS キューを作成します。Amazon MWAA は、 AWS 所有の KMS キーまたは指定したカスタマー管理の KMS キーを使用して、SSE を使用してキューとの間で送受信されるデータの暗号化を処理します。 AWS 所有またはカスタマー管理の KMS キーを使用しているかどうかにかかわらず、実行ロールに Amazon SQS アクセス許可を追加する必要があります。
**Aurora PostgreSQL** — Amazon MWAA は、お使いの環境に合わせて 1 つの PostgreSQL クラスターを作成します。Aurora PostgreSQL は、SSE を使用して AWS 、所有またはカスタマー管理の KMS キーでコンテンツを暗号化します。カスタマーマネージドの KMS キーを使用している場合、Amazon RDS はキーに少なくとも 2 つの権限を追加します。1 つはクラスター用、もう 1 つはデータベースインスタンス用です。カスタマーマネージド KMS キーを複数の環境で使用することを選択した場合、Amazon RDS は追加の権限を作成することがあります。詳細については、[Amazon RDS におけるデータ保護](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/DataDurability.html) を参照してください。
## 転送中の暗号化
転送中のデータとは、ネットワークを移動する際に傍受される可能性があるデータと呼ばれます。
Transport Layer Security (TLS) は、環境の Apache Airflow コンポーネントと Amazon S3 などの Amazon MWAA と統合する他の AWS サービスの間で転送中の Amazon MWAA オブジェクトを暗号化します。Amazon S3 暗号化の使用の詳細については、[暗号化でデータを保護する](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) を参照してください。
# 暗号化のためのカスタマーマネージドキーの使用
オプションで、環境内のデータ暗号化するための [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) を提供できます。カスタマーマネージド KMS キーは、Amazon MWAA 環境インスタンスと、ワークフローのリソースを保存する Amazon S3 バケットと同じリージョンに作成する必要があります。指定するカスタマーマネージド KMS キーが、クラスターの構成に使用するアカウントとは異なるアカウントにある場合は、その ARN を使用してキーをクロスアカウントアクセスに指定する必要があります。キーの作成の詳細については、*AWS Key Management Service デベロッパーガイド* の [キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) を参照してください。
## サポート対象
| AWS KMS 機能 | サポート |
| --- | --- |
| [AWS KMS キー ID または ARN](https://docs.aws.amazon.com/kms/latest/developerguide/find-cmk-id-arn.html)。 | はい |
| [AWS KMS キーエイリアス](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html)。 | いいえ |
| [AWS KMS マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)。 | いいえ |
## 暗号化のための許可の使用
このトピックでは、データの暗号化および復号化のために、Amazon MWAA がお客様に代わってカスタマーマネージド KMS キーに付与する許可について説明します。
### 仕組み
カスタマーマネージド KMS キー AWS KMS では、 でサポートされるリソースベースのアクセスコントロールメカニズムとして、[キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)と[グラント](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)の 2 つがあります。
キーポリシーは、権限がほとんど静的で、同期サービスモードで使用される場合に使用されます。許可は、サービスが自身や他のアカウントに異なるアクセス許可を定義する必要がある場合など、より動的で詳細な権限が必要な場合に使用されます。
Amazon MWAA では、4 つの付与ポリシーを使用してカスタマーマネージド KMS キーにアタッチします。これは、CloudWatch Logs、Amazon SQS キュー、Aurora PostgreSQL データベース、Secrets Manager シークレット、Amazon S3 バケット、DynamoDB テーブルからの保管中のデータを暗号化するために環境に必要な、きめ細かいアクセス許可があるためです。
Amazon MWAA 環境を作成してカスタマーマネージド KMS キーを指定すると、Amazon MWAA はその許可ポリシーをカスタマーマネージド KMS キーにアタッチします。これらのポリシーにより、`airflow.us-east-1.amazonaws.com` 内の Amazon MWAA はお客様のカスタマーマネージド KMS キーを使用して、お客様に代わって Amazon MWAA が所有するリソースを暗号化することができます。
Amazon MWAA は、お客様に代わって指定された KMS キーに追加の権限を作成し、アタッチします。これには、環境を削除した場合に権限を廃止するポリシー、クライアント側の暗号化 (CSE) にカスタマーマネージド KMS キーを使用するポリシー、Secrets Manager のカスタマーマネージドキーで保護されたシークレットにアクセスする必要がある AWS Fargate 実行ロールが含まれます。
## 許可ポリシー
Amazon MWAA は、お客様に代わって以下の [リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) 許可をカスタマーマネージドの KMS キーに追加します。これらのポリシーにより、被付与者とプリンシパル (Amazon MWAA) は、ポリシーで定義されたアクションを実行できます。
### 許可 1: データプレーンリソースの作成に使用
```
{
"Name": "mwaa-grant-for-env-mgmt-role-environment name",
"GranteePrincipal": "airflow.us-east-1.amazonaws.com",
"RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
"Operations": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey",
"kms:RetireGrant"
]
}
```
### 許可 2: `ControllerLambdaExecutionRole` アクセスに使用
```
{
"Name": "mwaa-grant-for-lambda-exec-environment name",
"GranteePrincipal": "airflow.us-east-1.amazonaws.com",
"RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
"Operations": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey",
"kms:RetireGrant"
]
}
```
### 許可 3: `CfnManagementLambdaExecutionRole` アクセスに使用
```
{
"Name": " mwaa-grant-for-cfn-mgmt-environment name",
"GranteePrincipal": "airflow.us-east-1.amazonaws.com",
"RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
"Operations": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
]
}
```
### 許可 4: バックエンドシークレットにアクセスするための Fargate 実行ロールに使用
```
{
"Name": "mwaa-fargate-access-for-environment name",
"GranteePrincipal": "airflow.us-east-1.amazonaws.com",
"RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
"Operations": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey",
"kms:RetireGrant"
]
}
```
## カスタマーマネージドキーへのキーポリシーの適用
Amazon MWAA で独自のカスタマーマネージド KMS キーを使用する場合は、Amazon MWAA がキーを使用してデータを暗号化できるように、以下のポリシーをキーにアタッチする必要があります。
Amazon MWAA 環境に使用したカスタマーマネージド KMS キーが CloudWatch と連携するようにまだ構成されていない場合は、暗号化された CloudWatch Logs を許可するように [キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) を更新する必要があります。詳細については、「 [AWS Key Management Service サービスを使用した CloudWatch のログデータの暗号化](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)」を参照してください。
次の例は、CloudWatch ログのキーポリシーを表しています。リージョンに提供されているサンプル値に置き換えてください。
```
{
"Effect": "Allow",
"Principal": {
"Service": "logs.us-east-1.amazonaws.com"
},
"Action": [
"kms:Encrypt*",
"kms:Decrypt*",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:Describe*"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:us-east-1:*:*"
}
}
}
```
# AWS Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するのに役立つ AWS サービスです。IAM 管理者は、誰を認証 (サインイン) し、誰に Amazon Managed Workflows for Apache Airflow リソースの使用を承認する (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS サービスです。
このトピックでは、Amazon MWAA が AWS Identity and Access Management (IAM) を使用する方法の基本的な概要を説明します。Amazon MWAA へのアクセスの管理については、[Amazon MWAA 環境へのアクセスの管理](manage-access.md) を参照してください。
**Topics**
+ [
## 対象者
](#security_iam_audience)
+ [
## アイデンティティを使用した認証
](#security_iam_authentication)
+ [
## ポリシーを使用したアクセスの管理
](#security_iam_access-manage)
+ [
## ユーザー自身のアクセス許可をアクセスすることをユーザーに許可する
](#security_iam_id-based-policy-examples-view-own-permissions)
+ [
# Amazon Managed Workflows for Apache Airflow のアイデンティティとアクセスのトラブルシューティング
](security_iam_troubleshoot.md)
+ [
# Amazon MWAA で IAM が機能する仕組み
](security_iam_service-with-iam.md)
## 対象者
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[Amazon Managed Workflows for Apache Airflow のアイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[Amazon MWAA で IAM が機能する仕組み](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[Amazon MWAA のアイデンティティベースポリシーの例](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 アカウント *ルートユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### 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 またはリソースにアタッチします。ポリシーは、ID またはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー 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 マネージドポリシーを使用できません。
### アクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、および Amazon VPC は AWS WAF、ACLs。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。
### その他のポリシータイプ
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)」を参照してください。
## ユーザー自身のアクセス許可をアクセスすることをユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を 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": "*"
}
]
}
```
# Amazon Managed Workflows for Apache Airflow のアイデンティティとアクセスのトラブルシューティング
以下の情報を使用して、Amazon MWAA と IAM の使用時に発生する可能性がある一般的な問題の診断と修正に役立てます。
## Amazon MWAA でアクションを実行する権限がありません
にアクションを実行する権限がないと AWS マネジメントコンソール 通知された場合は、管理者に連絡してサポートを依頼する必要があります。担当の管理者はお客様のユーザー名とパスワードを発行した人です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon MWAA にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
次の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Amazon MWAA でアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## 自分の 以外のユーザーに Amazon MWAA リソース AWS アカウント へのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ Amazon MWAA がこれらの機能をサポートしているかどうかを確認するには、[Amazon MWAA で IAM が機能する仕組み](security_iam_service-with-iam.md) を参照してください。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
# Amazon MWAA で IAM が機能する仕組み
Amazon MWAA は IAM アイデンティティベースのポリシーを使用して、Amazon MWAA アクションおよびリソースにアクセス許可を付与します。Amazon MWAA リソースへのアクセスを制御するために使用できるカスタム IAM ポリシーの推奨例については、[Amazon MWAA 環境へのアクセス](access-policies.md) を参照してください。
Amazon MWAA およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Amazon MWAA アイデンティティベースのポリシー
IAM アイデンティティベースポリシーでは、許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。Amazon MWAA は、特定のアクション、リソース、および条件キーをサポートしています。
次の手順では、IAM コンソールを使用して新しい JSON ポリシーを作成する方法を示します。このポリシーは、Amazon MWAA リソースへの読み取り専用アクセスを提供します。
**JSON ポリシーエディタでポリシーを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。
初めて **[ポリシー]** を選択する場合には、**[管理ポリシーにようこそ]** ページが表示されます。**今すぐ始める** を選択します。
1. ページの上部で、**[ポリシーを作成]** を選択します。
1. **ポリシーエディタ** セクションで、**JSON** オプションを選択します。
1. 次の JSON ポリシードキュメントを入力します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"airflow:ListEnvironments",
"airflow:GetEnvironment",
"airflow:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
1. **次へ** を選択します。
**注記**
いつでも **Visual** と **JSON** エディタオプションを切り替えることができます。ただし、**[ビジュアル]** エディタで **[次へ]** に変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、*IAM ユーザーガイド* の [ポリシーの再構成](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html#troubleshoot_viseditor-restructure) を参照してください。
1. **確認と作成** ページで、作成するポリシーの **ポリシー名** と **説明** (オプション) を入力します。**このポリシーで定義されているアクセス許可** を確認して、ポリシーによって付与されたアクセス許可を確認します。
1. **ポリシーを作成** をクリックして、新しいポリシーを保存します。
JSON ポリシーで使用するすべての要素については、*IAM ユーザーガイド* の[IAM JSON ポリシー要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) を参照してください。
### アクション
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
ポリシーステートメントには、`Action` 要素または `NotAction` 要素を含める必要があります。`Action` 要素は、ポリシーによって許可されるアクションをリストします。`NotAction` 要素は、許可されていないアクションをリストします。
Amazon MWAA のために定義されたアクションには、Amazon MWAA を使用して実行できるタスクが反映されます。Detective のポリシーアクションには、プレフィックス `airflow:` が付いています。
複数のアクションを指定するために、ワイルドカード (\$1) を使用することもできます。これらのアクションを個別にリストする代わりに、例えば `environment` という単語で終わるすべてのアクションへのアクセス権を付与できます。
Amazon MWAA アクションのリストを確認するには、*IAM ユーザーガイド* の [Amazon Managed Workflows for Apache Airflow で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_mwaa.html#mwaa-actions-as-permissions)を参照してください。
# Amazon MWAA のアイデンティティベースポリシーの例
Amazon MWAA ポリシーにアクセスするには、[Amazon MWAA 環境へのアクセスの管理](manage-access.md) を参照してください。
デフォルトでは、IAM ユーザーおよびロールには Amazon MWAA リソースを作成または変更するアクセス許可はありません。また、 AWS マネジメントコンソール、 AWS CLI、または AWS API を使用してタスクを実行することはできません。
IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。その後、管理者はそれらの許可が必要な IAM ユーザーまたはグループにそのポリシーをアタッチします。
**重要**
IAM ロールと一時的な認証情報を使用して Amazon MWAA リソースにアクセスすることをお勧めします。アクセス権限ポリシーを IAM ユーザーに直接アタッチすることは避けてください。
JSON ポリシードキュメントのこれらの例を使用して、IAM アイデンティティベースのポリシーを作成する方法については、*IAM ユーザーガイド* の [JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) を参照してください。
**Topics**
+ [
## ポリシーに関するベストプラクティス
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Amazon MWAA コンソールの使用
](#security_iam_id-based-policy-examples-console)
+ [
## ユーザー自身のアクセス許可をアクセスすることをユーザーに許可する
](#security_iam_id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
アイデンティティベースのポリシーは、アカウント内で誰が Amazon MWAA リソースを作成、アクセス、または削除できるを決定します。これらのアクションでは、 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) を参照してください。
## Amazon MWAA コンソールの使用
Amazon MWAA コンソールを使用するには、ユーザーまたはロールが、関連するアクションであって、API の対応するアクションに一致するアクションにアクセスできる必要があります。
Amazon MWAA ポリシーにアクセスするには、[Amazon MWAA 環境へのアクセスの管理](manage-access.md) を参照してください。
## ユーザー自身のアクセス許可をアクセスすることをユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を 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": "*"
}
]
}
```
# Amazon Managed Workflows for Apache Airflow のコンプライアンス検証
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/)」を参照してください。
# Amazon Managed Workflows for Apache Airflow におけるレジリエンス
AWS グローバルインフラストラクチャは、 AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。リージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立および隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、フォールトトレランス、および拡張性が優れています。
AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
# Amazon MWAA のインフラストラクチャセキュリティ
マネージドサービスである Amazon Managed Workflows for Apache Airflow は、 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 コールを使用して、ネットワーク経由で Amazon MWAA にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
# Amazon MWAA での設定と脆弱性の分析
設定と IT コントロールは、 AWS とお客様の間の責任共有です。
Amazon Managed Workflows for Apache Airflow に定期的にパッチを適用し、環境の Apache Airflow をアップグレードします。VPC に適切なアクセスポリシーが使用されていることを確認します。
詳細については、以下のリソースを参照してください。
+ [Amazon Managed Workflows for Apache Airflow のコンプライアンス検証](compliance-validation.md)
+ [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Amazon Web Services: セキュリティプロセスの概要](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf)
+ [Amazon MWAA のインフラストラクチャセキュリティ](infrastructure-security.md)
+ [Amazon MWAA のセキュリティのベストプラクティス](security-best-practices.md)
# Amazon MWAA のセキュリティのベストプラクティス
Amazon MWAA には、独自のセキュリティポリシーを策定および実装する際に考慮すべきさまざまなセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは指示ではなく、有用な考慮事項と見なしてください。
+ 最小許可ポリシーを使用します。ユーザーがタスクを実行するのに必要なリソースまたはアクションのみにアクセス許可を付与します。
+ AWS CloudTrail を使用して、アカウントのユーザーアクティビティをモニタリングします。
+ Amazon S3 バケットポリシーとオブジェクト ACL が、関連する Amazon MWAA 環境のユーザーにオブジェクトをバケットに入れるアクセス許可を付与していることを確認してください。これにより、バケットにワークフローを追加するアクセス許可を持つユーザーには、Airflow でワークフローを実行するアクセス許可も付与されます。
+ Amazon MWAA 環境に関連付けられた Amazon S3 バケットを使用します。お使いの Amazon S3 バケットにはどのような名前でもかまいません。他のオブジェクトをバケットに保存したり、別のサービスでバケットを使用したりしないでください。
## Apache Airflow でのセキュリティのベストプラクティス
Apache Airflow はマルチテナントではありません。特定のユーザーに一部の機能を制限する [アクセス制御手段](https://airflow.apache.org/docs/apache-airflow/2.0.2/security/access-control.html) があり、[Amazon MWAA が実装](access-policies.md#web-ui-access) している一方で、DAG 作成者は Apache Airflow ユーザー権限を変更し、基盤となるメタデータベースと対話する DAG を記述する能力を持っています。
Amazon MWAA で Apache Airflow を使用するときは、環境のメタデータデータベースと DAG の安全を確保するために、次の手順を実行することをお勧めします。
+ [Amazon MWAA 実行ロール](mwaa-create-role.md) または [Apache Airflow 接続](https://airflow.apache.org/docs/apache-airflow/2.0.2/howto/connection.html) でアクセスできるものには、その環境に書き込むことができるユーザーもアクセスできると仮定して、DAG 書き込みアクセス権を持つチームや Amazon S3 `/dags` フォルダにファイルを追加できる個別のチームには、別々の環境を使用してください。
+ Amazon S3 DAG フォルダへの直接アクセスを提供しないでください。代わりに、CI/CD ツールを使用して Amazon S3 に DAG を書き込み、DAG コードがチームのセキュリティガイドラインを満たしていることを確認する検証ステップを行います。
+ お使いの環境の Amazon S3 バケットへのユーザーアクセスを防ぎます。代わりに、DAG を格納するお使いの Amazon MWAA Amazon S3 バケットとは別の場所に保存されている YAML、JSON、またはその他の定義ファイルに基づいて DAG を生成する DAG ファクトリを使用してください。
+ [Secrets Manager](connections-secrets-manager.md) でシークレットを管理するには これにより、DAG を作成できるユーザーがシークレットを読み取ることができなくなるわけではありませんが、環境が使用するシークレットをユーザーが変更することはできなくなります。
### Apache Airflow ユーザー権限の変更を検出します。
CloudWatch Logs Insights では Apache Airflow のユーザー権限が変更される DAG の発生を検出できます。そのためには、EventBridge のスケジュールルール、Lambda 関数、および CloudWatch Logs インサイトを使用して、DAG の 1 つが Apache Airflow ユーザー権限を変更するたびに CloudWatch メトリクスに通知を配信できます。
#### 前提条件
このセクションの手順を完了するには、次のものが必要です。
+ すべての Apache Airflow ログタイプが `INFO` ログレベルで有効になっている Amazon MWAA 環境。詳細については、[Amazon CloudWatch の Airflow ログへのアクセス](monitoring-airflow.md) を参照してください。
**Apache Airflow ユーザー権限が変更された際の通知を設定するには**
1. 5 つの Amazon MWAA 環境ロググループ (`DAGProcessing`、`Scheduler`、`Task`、`WebServer` および `Worker`) に対して次の CloudWatch Logs Insights クエリ文字列を実行する [Lambda 関数を作成](https://docs.aws.amazon.com/lambda/latest/dg/getting-started-create-function.html) します。
```
fields @log, @timestamp, @message | filter @message like "add-role" | stats count() by @log
```
1. 前のステップで作成した Lambda 関数をルールのターゲットとして、[スケジュールに従って実行される EventBridge ルールを作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html) します。cron または rate 式を使用して、定期的に実行されるようにスケジュールを構成します。