AWS ポリシー

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間：15分

    • クラウドコンフィグレーションガバナンス AWS ポリシーが参照用にリストされています。

    表 : 1. クラウドコンフィグレーションガバナンス AWS ポリシー
    ポリシーセット ポリシー名 リソースタイプ 説明
    AWS IAM ユーザーアクティビティポリシー 条件ビルダー AWS IAM ユーザーに対してパスワードが有効かどうかを確認するポリシー。
    このポリシーを使用するには、AWSIAM ユーザーアカウントに次の権限があることを確認してください。
    • Iam:GetCredentialReport
    • Iam:GenerateCredentialReport
    AWS S3 の強制バケット暗号化 条件ビルダー AWS S3 のバケットが暗号化されているかどうかを確認するポリシー。
    AWS サンプルフローポリシー 統合ハブ フロー 統合ハブ フローベースのポリシーを説明するポリシー。
    AWS VM のハードウェアタイプ 条件ビルダー 展開された EC2 VM が承認されたハードウェアタイプのみを使用しているかどうかを確認するポリシー。
    AWS VM IP アドレス スクリプト EC2 VM の IP アドレスが 構成管理データベース (CMDB) レコードと一致しているかどうかを確認するポリシー。
    AWS VM 監視状況 条件ビルダー EC2 VM に対して詳細な監視が有効になっているかどうかを確認するポリシー。
    AWS:IAM セキュリティ コンソールパスワードを持つすべての IAM ユーザーに対してマルチファクター認証 (MFA) が有効になっていることを確認する (自動) IAM ユーザー

    マルチファクター認証 (MFA) は、従来の認証情報を超える認証保証のレイヤーを追加します。MFA を有効にすると、ユーザーが AWS コンソールにサインインすると、ユーザー名とパスワード、および物理または仮想 MFA トークンからの認証コードの入力が求められます。コンソールパスワードを持つすべてのアカウントに対して MFA を有効にすることをお勧めします。

    MFA を有効にすると、認証プリンシパルが時間的制約のあるキーを表示し、認証情報に関する知識を持っているデバイスを所有する必要があるため、コンソールアクセスのセキュリティが強化されます。
    45 日間以上使用されていない認証情報が無効になっていることを確認します (自動) IAM ユーザー

    AWS IAM ユーザーは、パスワードやアクセスキーなどのさまざまなタイプの認証情報を使用して AWS リソースにアクセスできます。45 日以上使用されていないすべての認証情報を非アクティブ化または削除することをお勧めします

    不要な認証情報を無効化または削除すると、侵害されたアカウントまたは放棄されたアカウントに関連付けられた認証情報が使用される機会が減ります。
    1 人の IAM ユーザーが使用できるアクティブなアクセスキーが 1 つのみであることを確認する (自動) IAM ユーザー

    アクセスキーは、IAM ユーザーまたは AWS アカウント「ルート」ユーザーの長期的な認証情報です。アクセスキーを使用して、AWS CLI または AWS API へのプログラムによるリクエストに (直接または AWS SDK を使用して) 署名できます

    アクセスキーは、IAM ユーザーまたは AWS アカウント「ルート」ユーザーの長期的な認証情報です。アクセスキーを使用して、AWS CLI または AWS API へのプログラムによるリクエストに署名できます。アカウントを保護する最善の方法の1つは、ユーザーに複数のアクセスキーを許可しないことです。
    アクセスキーが 90 日以下ごとにローテーションされるようにする (自動化) IAM ユーザー

    アクセスキーは、アクセスキー ID と秘密アクセスキーで構成され、AWS に対して行うプログラムによるリクエストに署名するために使用されます。AWS ユーザーは、AWS Command Line Interface (AWS CLI)、Tools for Windows PowerShell、AWS SDK から AWS へのプログラムによる呼び出しを行うか、個々の AWS サービスの API を使用して直接 HTTP 呼び出しを行うには、独自のアクセスキーが必要です。すべてのアクセスキーを定期的にローテーションすることをお勧めします。

    アクセス キーをローテーションすると、侵害または終了したアカウントに関連付けられているアクセス キーを使用する機会が減ります。

    アクセスキーはローテーションして、紛失、解読、または盗難の可能性のある古いキーでデータにアクセスできないようにする必要があります。
    IAM ユーザーがグループを通じてのみ権限を受け取るようにする (自動) IAM ユーザー

    IAM ユーザーには、IAM ポリシーを通じてサービス、機能、およびデータへのアクセス権が付与されます。

    ユーザーのポリシーを定義するには、次の 3 つの方法があります。
    1. ユーザーポリシー、つまりインライン、ユーザー、ポリシーを直接編集します。
    2. ポリシーをユーザーに直接添付します。
    3. ポリシーが添付されている IAM グループにユーザーを追加します。

    3 番目の実装のみをお勧めします。

    グループにのみ IAM ポリシーを割り当てると、組織の機能ロールと一致する単一の柔軟なレイヤーに権限管理が統合されます。権限管理を一元化することで、過剰な権限が発生する可能性を減らします。
    完全な「*:*」管理権限を許可する IAM ポリシーがアタッチされていないことを確認します (自動) IAM ユーザー

    IAM ポリシーは、ユーザー、グループ、またはロールに権限を付与する手段です。最低限の権限を付与すること、つまり、タスクを実行するために必要な権限のみを付与することが推奨され、標準的なセキュリティアドバイスと見なされます。ユーザーが何をする必要があるかを判断し、完全な管理者特権を許可する代わりに、ユーザーがそれらのタスクのみを実行できるようにするポリシーを作成します。

    寛大すぎる権限から始めて後で厳しくするよりも、最小限の権限セットから始めて、必要に応じて追加の権限を付与する方が安全です。

    ユーザーに必要な最小限のアクセス許可セットを制限するのではなく、完全な管理特権を提供すると、リソースが望ましくない可能性のあるアクションにさらされます。

    "Resource": "" に対する "Effect": "Allow" と "Action": "" のステートメントを持つ IAM ポリシーは削除する必要があります。
    AWS Support でインシデントを管理するためのサポートロールが作成されていることを確認する (自動) IAM ユーザー

    AWS は、インシデントの通知と応答に使用できるサポートセンター、およびテクニカルサポートとカスタマーサービスを提供しています。IAM ロールを作成して、許可されたユーザーが AWS Support でインシデントを管理できるようにします。

    アクセスコントロールの最小権限を実装することにより、IAM ロールには、AWS Support でインシデントを管理するためにサポートセンターへのアクセスを許可する適切な IAM ポリシーが必要になります。
    AWS IAM に保存されているすべての期限切れの SSL/TLS 証明書が削除されていることを確認します (自動) IAM ユーザー

    AWS でウェブサイトまたはアプリケーションへの HTTPS 接続を有効にするには、SSL/TLS サーバー証明書が必要です。ACM または IAM を使用して、サーバー証明書を保存および展開できます。IAM を証明書マネージャーとして使用するのは、ACM でサポートされていないリージョンで HTTPS 接続をサポートする必要がある場合のみです。IAMは秘密キーを安全に暗号化し、暗号化されたバージョンをIAM SSL証明書ストレージに保存します。IAM は、すべてのリージョンでのサーバー証明書のデプロイをサポートしていますが、AWS で使用するには外部プロバイダーから証明書を取得する必要があります。ACM 証明書を IAM にアップロードすることはできません。また、IAM コンソールから証明書を管理することはできません。

    期限切れの SSL/TLS 証明書を削除すると、無効な証明書が誤って AWS Elastic Load Balancer (ELB) などのリソースにデプロイされ、ELB の背後にあるアプリケーション/Web サイトの信頼性が損なわれるリスクがなくなります。ベストプラクティスとして、期限切れの証明書を削除することをお勧めします。
    すべてのリージョンで IAM アクセスアナライザーが有効になっていることを確認する (自動) AWS::AccessAnalyzer::Analyzer

    各リージョンのすべてのリソースに関する IAM ポリシーの IAM アクセスアナライザーを有効にします。

    IAM Access Analyzer は、AWS reinvent 2019 で導入されたテクノロジーです。IAMでアナライザを有効にすると、スキャン結果がコンソールに表示され、アクセス可能なリソースが表示されます。スキャンでは、KMS キーや IAM ロールなど、他のアカウントやフェデレーティッドユーザーがアクセスできるリソースが表示されます。その結果から、意図しないユーザーが許可されているかどうかを判断できるため、管理者は最小限の特権アクセスを簡単に監視できます。アクセスアナライザーは、同じ AWS リージョン 内のリソースに適用されるポリシーのみを分析します。

    AWS IAM Access Analyzer は、外部エンティティと共有されている組織内およびアカウント (Amazon S3 バケットや IAM ロールなど) を特定するのに役立ちます。これにより、リソースとデータへの意図しないアクセスを特定できます。Access Analyzer は、ロジックベースの推論を使用して AWS 環境のリソースベースのポリシーを分析することで、外部プリンシパルと共有されているリソースを識別します。IAM Access Analyzer は、S3 バケット、IAM ロール、KMS (Key Management Service) キー、AWS Lambda 関数、Amazon SQS (Simple Queue Service) キューのすべてのポリシーを継続的に監視します。
    「ルート」ユーザーアカウントアクセスキーが存在しないことを確認する (自動) IAM ユーザー

    「ルート」ユーザーアカウントは、AWS アカウントで最も特権の高いユーザーです。AWS アクセスキーは、特定の AWS アカウントへのプログラムによるアクセスを提供します。「ルート」ユーザーアカウントに関連付けられているすべてのアクセスキーを削除することをお勧めします。

    「ルート」ユーザーアカウントに関連付けられたアクセスキーを削除すると、アカウントが侵害される可能性のあるベクトルが制限されます。さらに、「ルート」アクセスキーを削除すると、最も特権の低いロールベースのアカウントの作成と使用が促進されます。
    「ルート」ユーザーアカウントに対して MFA が有効になっていることを確認する (自動) IAM ユーザー

    「ルート」ユーザーアカウントは、AWS アカウントで最も特権の高いユーザーです。マルチファクター認証 (MFA) は、ユーザー名とパスワードの上に保護レイヤーを追加します。MFA を有効にすると、ユーザーが AWS ウェブサイトにサインインすると、ユーザー名とパスワード、および AWS MFA デバイスからの認証コードの入力が求められます。

    MFA を有効にすると、認証プリンシパルが時間的制約のあるキーを発行するデバイスを所有し、認証情報に関する知識を持っている必要があるため、コンソールアクセスのセキュリティが強化されます。
    「ルート」ユーザーアカウントに対してハードウェア MFA が有効になっていることを確認します (自動) IAM ユーザー

    「ルート」ユーザーアカウントは、AWS アカウントで最も特権の高いユーザーです。MFA は、ユーザー名とパスワードの上に保護レイヤーを追加します。MFA を有効にすると、ユーザーが AWS ウェブサイトにサインインすると、ユーザー名とパスワード、および AWS MFA デバイスからの認証コードの入力が求められます。レベル 2 では、「ルート」ユーザーアカウントをハードウェア MFA で保護することをお勧めします。

    ハードウェア MFA は、仮想 MFA よりも攻撃対象領域が小さくなります。たとえば、ハードウェア MFA は、仮想 MFA が存在するモバイル スマートフォンによって導入される攻撃対象領域の影響を受けません。
    管理タスクや日常業務での「ルート」ユーザーの使用を排除 (自動化) IAM ユーザー

    AWS アカウントを作成すると、無効化または削除できない「ルートユーザー」が作成されます。そのユーザーは、AWS アカウント内のすべてのリソースに無制限にアクセスし、制御できます。このアカウントは、日常業務には使用しないことを強くお勧めします。

    「ルートユーザー」は、すべてのアカウントリソースに対して無制限のアクセス権を持ち、制御できます。その使用は、最小特権と職務の分離の原則と矛盾し、エラーやアカウントの侵害による不必要な損害につながる可能性があります。
    IAM パスワードポリシーで最小長を 14 以上にする必要があることを確認する (自動) IAM ユーザー

    パスワードポリシーは、パスワードの複雑さの要件を強制するために部分的に使用されます。IAMパスワード・ポリシーを使用して、パスワードが少なくとも指定された長さであることを確認できます。パスワードポリシーでは、パスワードの最小長を 14 にすることをお勧めします。

    パスワードの複雑さのポリシーを設定すると、総当たりログイン試行に対するアカウントの回復力が向上します。
    IAM パスワードポリシーでパスワードの再利用を防止する (自動) IAM ユーザー

    IAM パスワードポリシーは、同じユーザーによる特定のパスワードの再利用を防止できます。パスワードポリシーでパスワードの再利用を防止することをお勧めします。

    パスワードの再利用を防止することで、総当たりログイン試行に対するアカウントの回復性が向上します。
    AWS:データセキュリティ S3 バケットが「パブリックアクセスをブロック (バケット設定)」で構成されていることを確認します AWS::S3::Bucket

    Amazon S3 には、Amazon S3 リソースへのパブリックアクセスの管理に役立つ Block public access (バケット設定) と Block public access (アカウント設定) が用意されています。デフォルトでは、S3 バケットとオブジェクトはパブリックアクセスを無効にして作成されます。ただし、十分な S3 アクセス許可を持つ IAM プリンシパルは、バケットやオブジェクトレベルでパブリックアクセスを有効にすることができます。有効にすると、ブロックパブリックアクセス(バケット設定)は、個々のバケットとその含まれているオブジェクトがパブリックアクセス可能になるのを防ぎます。同様に、ブロックパブリックアクセス(アカウント設定)は、すべてのバケットと含まれているオブジェクトがアカウント全体でパブリックアクセス可能になるのを防ぎます。

    Amazon S3 のパブリックアクセスのブロック (バケット設定) は、それぞれのバケット内に含まれるデータが偶発的または悪意を持ってパブリックに公開されるのを防ぎます。

    Amazon S3 のパブリックアクセスのブロック (アカウント設定) は、それぞれの AWS アカウントのすべてのバケット内に含まれるデータが偶発的または悪意を持って公開されるのを防ぎます。

    すべてのバケットまたは一部のバケットへのパブリックアクセスをブロックするかどうかは、データの機密性、最小権限、およびユースケースに基づく組織の決定である必要があります。
    AWS:CloudTrail ログ記録 書き込みイベントのオブジェクトレベルのログ記録が S3 バケットで有効になっていることを確認します (自動) AWS::S3::Bucket

    GetObject、DeleteObject、PutObject などの S3 オブジェクトレベルの API オペレーションは、データイベントと呼ばれます。デフォルトでは、CloudTrail 証跡はデータイベントを記録しないため、

    S3 バケットのオブジェクトレベルのログ記録を有効にします。

    根拠 :

    オブジェクトレベルのログ記録を有効にすると、組織内のデータコンプライアンス要件を満たし、包括的なセキュリティ分析を実行し、ユーザーの特定のパターンを監視するのに役立ちます

    AWS アカウントで動作するか、Amazon CloudWatch Events を使用して S3 バケット内のオブジェクトレベルの API アクティビティに対して即時アクションを実行します。
    AWS:CloudTrail ログ記録 読み取りイベントのオブジェクトレベルのログ記録が S3 バケットで有効になっていることを確認します (自動) AWS::S3::Bucket

    GetObject、DeleteObject、PutObject などの S3 オブジェクトレベルの API オペレーションは、データイベントと呼ばれます。デフォルトでは、CloudTrail 証跡はデータイベントを記録しないため、

    S3 バケットのオブジェクトレベルのログ記録を有効にします。

    根拠 :

    オブジェクトレベルのログ記録を有効にすると、組織内のデータコンプライアンス要件を満たし、包括的なセキュリティ分析を実行し、ユーザーの特定のパターンを監視するのに役立ちます

    AWS アカウントで動作するか、Amazon CloudWatch Events を使用してオブジェクトレベルの API アクティビティに対して即時アクションを実行します。
    AWS:ネットワークセキュリティ ネットワーク ACL で 0.0.0.0/0 からリモートサーバー管理ポートへのイングレスが許可されていないことを確認する (自動) AWS::EC2::NetworkAcl

    ネットワークアクセス制御リスト (NACL) 機能は、AWS リソースへのイングレスおよびエグレスネットワークトラフィックのステートレスフィルタリングを提供します。NACL では、ポート 22 への SSH やポート 3389 への RDP など、リモート サーバー管理ポートへの無制限のイングレス アクセスを許可しないことを推奨します。

    22 や 3389 などのリモート サーバー管理ポートへのパブリック アクセスは、リソースの攻撃対象領域を拡大し、リソース侵害のリスクを不必要に高めます。
    AWS:ネットワークセキュリティ 0.0.0.0/0 からリモートサーバー管理ポートへのイングレスが許可されているセキュリティグループがないことを確認する (自動) AWS::EC2::SecurityGroup

    セキュリティグループは、AWS リソースへのイングレスおよびエグレスネットワークトラフィックのステートフルフィルタリングを提供します。SSH からポート 22 への SSH やポート 3389 への RDP など、リモート サーバー管理ポートへの無制限のイングレス アクセスを許可するセキュリティ グループがないことをお勧めします

    22 や 3389 などのリモート サーバー管理ポートへのパブリック アクセスは、リソースの攻撃対象領域を拡大し、リソース侵害のリスクを不必要に高めます。