ID とアクセスのセキュリティに関する推奨事項

[アーティクル]
09/06/2024

この記事では、Microsoft Defender for Cloud に表示される可能性があるすべての ID とアクセスセキュリティに関する推奨事項の一覧を示します。

環境に表示される推奨事項は、保護するリソースとカスタマイズした構成に基づいています。

これらの推奨事項に応じて実行できるアクションについては、「Defender for Cloud で推奨事項を修復するを参照してください。

ヒント

推奨事項の説明に 関連ポリシーがない、通常は、その推奨事項が別の推奨事項に依存しているためです。

たとえば、推奨事項 エンドポイント保護の正常性エラーを修復する必要があります は、エンドポイント保護ソリューションがインストールされているかどうかを確認する推奨事項に依存します (エンドポイント保護ソリューションをインストールする必要があります)。基になる推奨事項にはポリシーが存在します。ポリシーを基本的な推奨事項のみに制限すると、ポリシー管理が簡略化されます。

Azure ID とアクセスに関する推奨事項

サブスクリプションに対して、最大 3 人の所有者を指定する必要がある

説明: 侵害された所有者アカウントによる侵害の可能性を減らすために、所有者アカウントの数を最大 3 に制限することをお勧めします (関連ポリシー: サブスクリプションには最大 3 人の所有者を指定する必要があります)。

重大度: 高

Azure リソースに対する所有者アクセス許可を持つアカウントで MFA を有効にする必要があります。

説明: パスワードのみを使用してユーザーを認証する場合は、攻撃ベクトルを開いたままにします。ユーザーは、複数のサービスに対して脆弱なパスワードを使用していることがよくあります。多要素認証 (MFA) を有効にすると、アカウントのセキュリティが向上し、ユーザーはシングルサインオン (SSO) を使用してほぼすべてのアプリケーションに対して認証できるようになります。多要素認証は、ユーザーがサインインプロセス中に別の形式の識別を求めるプロセスです。たとえば、コードが携帯電話に送信されたり、指紋スキャンを求められたりすることがあります。侵害や攻撃を防ぐために、Azure リソースの所有者アクセス許可を持つすべてのアカウントに対して MFA を有効にすることをお勧めします。詳細とよく寄せられる質問については、サブスクリプションに対する多要素認証 (MFA) の適用の管理 (関連ポリシーなし) をご覧ください。

重大度: 高

Azure リソースに対する読み取りアクセス許可を持つアカウントで MFA を有効にする必要があります。

説明: パスワードのみを使用してユーザーを認証する場合は、攻撃ベクトルを開いたままにします。ユーザーは、複数のサービスに対して脆弱なパスワードを使用していることがよくあります。多要素認証 (MFA) を有効にすると、アカウントのセキュリティが向上し、ユーザーはシングルサインオン (SSO) を使用してほぼすべてのアプリケーションに対して認証できるようになります。多要素認証は、ユーザーがサインインプロセス中に追加の形式の識別を求めるプロセスです。たとえば、コードが携帯電話に送信されたり、指紋スキャンを求められたりすることがあります。侵害や攻撃を防ぐために、Azure リソースの読み取りアクセス許可を持つすべてのアカウントに対して MFA を有効にすることをお勧めします。詳細とよく寄せられる質問については、。 (関連ポリシーはありません)

重大度: 高

Azure リソースに対する書き込みアクセス許可を持つアカウントで MFA を有効にする必要があります。

説明: パスワードのみを使用してユーザーを認証する場合は、攻撃ベクトルを開いたままにします。ユーザーは、複数のサービスに対して脆弱なパスワードを使用していることがよくあります。多要素認証 (MFA) を有効にすると、アカウントのセキュリティが向上し、ユーザーはシングルサインオン (SSO) を使用してほぼすべてのアプリケーションに対して認証できるようになります。多要素認証は、ユーザーがサインインプロセス中に追加の形式の識別を求めるプロセスです。たとえば、コードが携帯電話に送信されたり、指紋スキャンを求められたりすることがあります。侵害や攻撃を防ぐために、Azure リソースの書き込みアクセス許可を持つすべてのアカウントに対して MFA を有効にすることをお勧めします。詳細とよく寄せられる質問については、サブスクリプションに対する多要素認証 (MFA) の適用の管理 (関連ポリシーなし) をご覧ください。

重大度: 高

Azure Cosmos DB アカウントで、Azure Active Directory を唯一の認証方法として使用する必要がある

説明: Azure サービスに対して認証を行う最善の方法は、ロールベースのアクセス制御 (RBAC) を使用することです。 RBAC を使用すると、最小特権の原則を維持でき、侵害が発生した場合の効果的な対処法としてアクセス許可を取り消す機能をサポートできます。唯一の認証方法として RBAC を実施するように Azure Cosmos DB アカウントを構成できます。実施が構成されると、他のすべてのアクセス方法 (プライマリ/セカンダリキーとアクセストークン) が拒否されます。 (関連ポリシーはありません)

重大度: 中

Azure リソースに対する所有者アクセス許可を持つブロックされたアカウントを削除する必要があります。

説明: Active Directory でのサインインがブロックされているアカウントは、Azure リソースから削除する必要があります。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシーはありません)

重大度: 高

Azure リソースの読み取りおよび書き込みアクセス許可を持つブロックされたアカウントは削除する必要がある

重大度: 高

非推奨のアカウントはサブスクリプションから削除する必要がある

説明: サインインがブロックされているユーザーアカウントは、サブスクリプションから削除する必要があります。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシー: 非推奨のアカウントは、サブスクリプションから削除する必要があります)。

重大度: 高

所有者アクセス許可を持つ非推奨のアカウントは、サブスクリプションから削除する必要がある

説明: サインインがブロックされているユーザーアカウントは、サブスクリプションから削除する必要があります。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシー: 所有者のアクセス許可を持つ非推奨のアカウントは、サブスクリプションから削除する必要があります)。

重大度: 高

Key Vault で診断ログを有効にする必要がある

説明: ログを有効にし、最大 1 年間保持します。これにより、セキュリティインシデントが発生した場合やネットワークが侵害された場合に、調査目的でアクティビティ証跡を再作成できます。 (関連ポリシー: Key Vault の診断ログを有効にする必要があります)。

重大度: 低

所有者のアクセス許可がある外部アカウントは、サブスクリプションから削除する必要がある

説明: 異なるドメイン名 (外部アカウント) を持つ所有者アクセス許可を持つアカウントは、サブスクリプションから削除する必要があります。これにより、監視されていないアクセスを防止できます。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシー: 所有者アクセス許可を持つ外部アカウントは、サブスクリプションから削除する必要があります)。

重大度: 高

読み取りアクセス許可がある外部アカウントは、サブスクリプションから削除する必要がある

説明: 異なるドメイン名 (外部アカウント) を持つ読み取りアクセス許可を持つアカウントは、サブスクリプションから削除する必要があります。これにより、監視されていないアクセスを防止できます。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシー: 読み取りアクセス許可を持つ外部アカウントは、サブスクリプションから削除する必要があります)。

重大度: 高

書き込みアクセス許可がある外部アカウントは、サブスクリプションから削除する必要がある

説明: 異なるドメイン名 (外部アカウント) を持つ書き込みアクセス許可を持つアカウントは、サブスクリプションから削除する必要があります。これにより、監視されていないアクセスを防止できます。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシー: 書き込みアクセス許可を持つ外部アカウントは、サブスクリプションから削除する必要があります)。

重大度: 高

キーコンテナーでファイアウォールを有効にする必要がある

説明: キーコンテナーのファイアウォールは、承認されていないトラフィックがキーコンテナーに到達するのを防ぎ、シークレットに対して追加の保護レイヤーを提供します。このファイアウォールを有効にして、許可されたネットワークからのトラフィックのみがキーコンテナーにアクセスできるようにします。 (関連ポリシー: Key Vault でファイアウォールを有効にする必要があります)。

重大度: 中

Azure リソースに対する所有者アクセス許可を持つゲストアカウントを削除する必要があります。

説明: Azure Active Directory テナント (異なるドメイン名) の外部でプロビジョニングされた所有者アクセス許可を持つアカウントは、Azure リソースから削除する必要があります。ゲストアカウントは、エンタープライズテナント ID と同じ標準に管理されません。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシーはありません)

重大度: 高

Azure リソースに対する読み取りアクセス許可を持つゲストアカウントを削除する必要があります。

説明: Azure Active Directory テナント (異なるドメイン名) の外部でプロビジョニングされた読み取りアクセス許可を持つアカウントは、Azure リソースから削除する必要があります。ゲストアカウントは、エンタープライズテナント ID と同じ標準に管理されません。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシーはありません)

重大度: 高

Azure リソースに対する書き込みアクセス許可を持つゲストアカウントを削除する必要があります。

説明: Azure Active Directory テナントの外部 (異なるドメイン名) の外部にプロビジョニングされた書き込みアクセス許可を持つアカウントは、Azure リソースから削除する必要があります。ゲストアカウントは、エンタープライズテナント ID と同じ標準に管理されません。これらのアカウントは、気付かれずにデータにアクセスする方法を見つけようとしている攻撃者の標的になるおそれがあります。 (関連ポリシーはありません)

重大度: 高

Key Vault キーには有効期限が必要である

説明: 暗号化キーには、永続的ではなく、定義された有効期限が設定されている必要があります。無期限に有効なキーを使用すると、攻撃者がキーを侵害できる時間がそれだけ長くなります。暗号化キーの有効期限を設定することをお勧めします。 (関連ポリシー: Key Vault キーには有効期限) が必要です。

重大度: 高

Key Vault シークレットには有効期限が必要である

説明: シークレットには、永続的ではなく、定義された有効期限が設定されている必要があります。シークレットを無期限に有効にすると、潜在的な攻撃者にそれを侵害する時間を多く与えることになります。シークレットに有効期限を設定することをお勧めします。 (関連ポリシー: Key Vault シークレットには有効期限) が必要です。

重大度: 高

キーコンテナーで消去保護が有効になっている必要がある

説明: キーコンテナーを悪意のある削除すると、データが完全に失われる可能性があります。組織内の悪意のある内部関係者が、キーコンテナーの削除と消去を実行できるおそれがあります。消去保護では、論理的に削除されたキーコンテナーに必須の保有期間を適用することによって、内部関係者の攻撃から組織を保護します。組織や Microsoft の内部にいるどのユーザーも、論理的な削除の保有期間中にキーコンテナーを消去することはできなくなります。 (関連ポリシー: キーコンテナーで消去保護が有効になっている必要があります)。

重大度: 中

キーコンテナーで論理的な削除が有効になっている必要がある

説明: 論理的な削除が有効になっていないキーコンテナーを削除すると、キーコンテナーに格納されているすべてのシークレット、キー、および証明書が完全に削除されます。誤ってキーコンテナーが削除されると、データが完全に失われる可能性があります。論理的な削除を使用すると、構成可能な保有期間の間は、誤って削除されたキーコンテナーを復旧できます。 (関連ポリシー: キーコンテナーで論理的な削除が有効になっている必要があります)。

重大度: 高

サブスクリプションに対して所有者アクセス許可があるアカウントでは、MFA を有効にする必要がある

説明: アカウントまたはリソースの侵害を防ぐために、所有者アクセス許可を持つすべてのサブスクリプションアカウントに対して多要素認証 (MFA) を有効にする必要があります。 (関連ポリシー: サブスクリプションに対する所有者アクセス許可を持つアカウントで MFA を有効にする必要があります)。

重大度: 高

サブスクリプションに対して読み取りアクセス許可があるアカウントでは、MFA を有効にする必要がある

説明: アカウントまたはリソースの侵害を防ぐために、読み取り特権を持つすべてのサブスクリプションアカウントに対して多要素認証 (MFA) を有効にする必要があります。 (関連ポリシー: サブスクリプションに対する読み取りアクセス許可を持つアカウントで MFA を有効にする必要があります)。

重大度: 高

サブスクリプションに対して書き込みアクセス許可があるアカウントでは、MFA を有効にする必要がある

説明: アカウントまたはリソースの侵害を防ぐために、書き込み特権を持つすべてのサブスクリプションアカウントに対して多要素認証 (MFA) を有効にする必要があります。 (関連ポリシー: MFA は、サブスクリプションに対する書き込みアクセス許可を持つアカウント) を有効にする必要があります。

重大度: 高

Microsoft Defender for Key Vaultを有効にする必要があります

説明: Microsoft Defender for Cloud には、セキュリティインテリジェンスの追加レイヤーを提供する Microsoft Defender for Key Vault が含まれています。 Microsoft Defender for Key Vault によって、異常であり、害を及ぼす可能性のある、Key Vault アカウントに対するアクセスまたは悪用の試みが検出されます。

このプランからの保護は、 Defender プラン ページに示されているように課金されます。このサブスクリプションにキーコンテナーがない場合、課金されることはありません。後でこのサブスクリプションにキーコンテナーを作成した場合は、自動的に保護され、課金が開始されます。詳細については、リージョン別の価格の詳細を参照してください。詳細については、「Microsoft Defender for Key Vault の概要」を参照してください。 (関連ポリシー: Azure Defender for Key Vault を有効にする必要があります)。

重大度: 高

Azure サブスクリプション内の非アクティブな ID のアクセス許可を取り消す必要がある

説明: Microsoft Defender for Cloud は、過去 45 日間に Azure サブスクリプション内のリソースに対して何もアクションを実行していない ID を検出しました。クラウド環境の攻撃対象領域を減らすために、非アクティブな ID のアクセス許可を取り消すことが推奨されます。

重大度: 中

Key Vault 用にプライベートエンドポイントを構成する必要がある

説明: プライベートリンクは、パブリックインターネット経由でトラフィックを送信することなく、Key Vault を Azure リソースに接続する方法を提供します。プライベートリンクにより、データ流出に対する徹底的な防御が提供されます。 (関連ポリシー: プライベートエンドポイントは、Key Vault) 用に構成する必要があります。

重大度: 中

ストレージアカウントのパブリックアクセスを禁止する必要がある

説明: Azure Storage のコンテナーと BLOB への匿名パブリック読み取りアクセスは、データを共有するための便利な方法ですが、セキュリティ上のリスクが発生する可能性があります。好ましくない匿名アクセスによるデータ侵害を防ぐために、Microsoft では、シナリオで必要でない限り、ストレージアカウントへのパブリックアクセスを禁止することをお勧めします。 (関連ポリシー: ストレージアカウントのパブリックアクセスは禁止する必要があります)。

重大度: 中

サブスクリプションに複数の所有者が割り当てられている必要がある

説明: 管理者アクセスの冗長性を確保するために、複数のサブスクリプション所有者を指定します。 (関連ポリシー: サブスクリプションに複数の所有者が割り当てられている必要があります)。

重大度: 高

Azure Key Vault に保存されている証明書の有効期間は 12 か月以内にする必要がある

説明: 証明書の有効期間が 12 か月を超えないようにします。 (関連ポリシー: 証明書には、指定された最大有効期間) が必要です。

重大度: 中

Azure のオーバープロビジョニングされた ID には、必要なアクセス許可のみが必要です (プレビュー)

説明: オーバープロビジョニングされた ID、またはアクセス許可を持つ ID を超えて、付与されたアクセス許可の多くを使用しません。これらの ID のアクセス許可を定期的に適切にサイズ変更して、アクセス許可の誤用のリスクを軽減します。これは、偶発的または悪意のあるアクセス許可です。このアクションにより、セキュリティインシデント中の潜在的な爆発半径が減少します。

重大度: 中

特権ロールは、サブスクリプションおよびリソースグループレベルで永続的なアクセス権を持つべきではない

説明: Microsoft Defender for Cloud は、過去 45 日間に Azure サブスクリプション内のリソースに対して何もアクションを実行していない ID を検出しました。クラウド環境の攻撃対象領域を減らすために、非アクティブな ID のアクセス許可を取り消すことが推奨されます。

重大度: 高

サービスプリンシパルには、サブスクリプションおよびリソースグループレベルで管理ロールを割り当てるべきではない

説明: リソースグループまたはサブスクリプションレベルで特権ロールが割り当てられている Defender for Cloud によって識別されたサービスプリンシパル。特権管理者ロールは、所有者、共同作成者、ユーザーアクセス管理者など、リソースに対して機密性の高い操作を実行できるロールです。サービスプリンシパルは、Azure リソースを効率的かつ安全に管理する上で重要な役割を果たし、人の介入を必要としません。最小限の特権の principle に従って特定のサービスプリンシパルが職務を実行するために必要な最小限のレベルのアクセス権のみを付与することが重要です。管理者と特権アクセスは、ハッカーの主なターゲットです。特権管理者ロールの割り当てを使用する場合のベストプラクティスについては、「Azure RBAC のベストプラクティス」を参照してください。 Azure RBAC のベストプラクティス。 Azure RBAC で使用可能なロールの一覧については、「 Azure の組み込みロールを参照してください。

重大度: 高

AWS ID とアクセスに関する推奨事項

Amazon Elasticsearch Service ドメインは、VPC に存在する必要がある

説明: VPC にパブリックエンドポイントを持つドメインを含めることはできません。これは、パブリック到達可能性を判断するために VPC サブネットルーティング構成を評価しません。

重大度: 高

バケットポリシーで他の AWS アカウントに許可された Amazon S3 アクセス許可は、制限する必要がある

説明: 最小限の特権アクセスの実装は、セキュリティリスクと、エラーや悪意のある意図の影響を軽減するための基本です。 S3 バケットポリシーで外部アカウントからのアクセスが許可されている場合、内部関係者の脅威または攻撃者によるデータ流出が発生する可能性があります。 'blacklistedactionpatterns' パラメーターを使用すると、S3 バケットの規則を正常に評価できます。このパラメーターは、'blacklistedactionpatterns' リストに含まれていないアクションパターンの外部アカウントへのアクセスを許可します。

重大度: 高

"root" アカウントの使用を避ける

説明: "root" アカウントには、AWS アカウント内のすべてのリソースへの無制限のアクセス権があります。このアカウントは使用しないことを強くお勧めします。 "root" アカウントは、最大限の特権が与えられた AWS アカウントです。このアカウントの使用を最小限にして、アクセス管理に最小限の特権の原則を採用することにより、高度な特権が含まれる資格情報を誤って変更したり、意図せずに公開したりするリスクを軽減できます。

重大度: 高

AWS KMS キーが誤って削除されないようにする必要がある

説明: このコントロールは、KMS キーの削除がスケジュールされているかどうかを確認します。このコントロールは、KMS キーの削除がスケジュールされている場合に失敗します。 KMS キーは、一度削除した後は復旧できません。また、KMS キーの下で暗号化されたデータは、KMS キーが削除された場合は、永続的に復元できなくなります。削除がスケジュールされている KMS キーで意味のあるデータが暗号化されている場合は、暗号化消去を意図的に実行しない限り、データの暗号化を解除するか、新しい KMS キーでデータを再暗号化することを検討してください。 KMS の削除がスケジュールされている場合、削除を元に戻す時間を許可するための、待機期間が必須で適用されます (誤ってスケジュールされていた場合)。既定の待機期間は 30 日ですが、KMS キーの削除がスケジュールされている場合は 7 日に短縮できます。待機期間中は、スケジュールされた削除を取り消すことができます。KMS キーは削除されません。 KMS キーの削除の詳細については、AWS キー管理サービス開発者ガイドの「 KMS キーの削除を参照してください。

重大度: 高

AWS のオーバープロビジョニングされた ID には、必要なアクセス許可のみが必要です (プレビュー)

説明: 過剰にプロビジョニングされたアクティブ ID は、使用していない特権にアクセスできる ID です。過剰にプロビジョニングされたアクティブな ID (特にアクションと責任が定義されている人間以外のアカウントの場合) は、ユーザー、キー、またはリソースが侵害された場合に、爆発半径が増加する可能性があります。不要なアクセス許可を削除し、最小限の特権のアクセス許可を実現するためのレビュープロセスを確立します。

重大度: 中

AWS WAF Classic グローバルウェブ ACL ログ記録は、有効にする必要がある

説明: このコントロールは、AWS WAF グローバル Web ACL に対してログ記録が有効になっているかどうかを確認します。 Web ACL に対してログ記録が有効になっていない場合、この制御は失敗します。ログ記録は、AWS WAF 全体の信頼性、可用性およびパフォーマンスを維持するうえで重要です。これは多くの組織のビジネスとコンプライアンスの要件であり、アプリケーションの動作のトラブルシューティングを行うことができます。また、AWS WAF にアタッチされているウェブ ACL によって分析されるトラフィックに関する詳細情報も提供します。

重大度: 中

CloudFront ディストリビューションでは、既定のルートオブジェクトを構成する必要がある

説明: このコントロールは、Amazon CloudFront ディストリビューションが既定のルートオブジェクトである特定のオブジェクトを返すように構成されているかどうかを確認します。 CloudFront ディストリビューションに既定のルートオブジェクトが構成されていない場合、コントロールは失敗します。ディストリビューションのオブジェクトではなく、ディストリビューションルート URL が、ユーザーによって要求される場合があります。このような場合は、既定のルートオブジェクトを指定すると、Web ディストリビューションの内容が公開されないようにすることができます。

重大度: 高

CloudFront ディストリビューションでは、オリジンアクセス ID を有効にする必要がある

説明: このコントロールは、Amazon S3 Origin タイプの Amazon CloudFront ディストリビューションに配信元アクセス ID (OAI) が構成されているかどうかを確認します。 OAI が構成されていない場合、コントロールは失敗します。 CloudFront OAI によって、ユーザーは、S3 バケットコンテンツに直接アクセスできなくなります。ユーザーが S3 バケットに直接アクセスすると、CloudFront ディストリビューションと、基になる S3 バケットコンテンツに適用されているアクセス許可が、事実上バイパスされます。

重大度: 中

CloudTrail ログファイル検証は、有効にする必要がある

説明: CloudTrail ログの整合性チェックを確実に追加するには、すべての CloudTrail でファイル検証を有効にすることをお勧めします。

重大度: 低

CloudTrail は、有効にする必要がある

説明: AWS CloudTrail は、アカウントの AWS API 呼び出しを記録し、ログファイルを配信する Web サービスです。すべての API とイベントに対して、すべてのサービスでログ記録が既定で有効になっているわけではありません。 CloudTrail 以外の監査証跡を追加で実装し、CloudTrail のサポートされているサービスと統合で、各サービスについてのドキュメントを確認する必要があります。

重大度: 高

CloudTrail 証跡は、CloudWatch ログに統合する必要がある

説明: 長期的な分析のために、指定された S3 バケット内の CloudTrail ログをキャプチャするだけでなく、CloudWatch ログにログを送信するように CloudTrail を構成することで、リアルタイム分析を実行できます。アカウント内のすべてのリージョンで有効になっている証跡の場合、CloudTrail によって、それらのすべてのリージョンから CloudWatch Logs のロググループにログファイルが送信されます。 AWS アカウントのアクティビティがキャプチャ、監視、および適切に警告表示されるようにするため、CloudTrail ログが CloudWatch Logs へ送信されるようにすることをお勧めします。 CloudTrail ログを CloudWatch Logs に送信すると、ユーザー、API、リソース、および IP アドレスに基づく、リアルタイムおよび履歴のアクティビティログ記録が促進され、異常な、または機密のアカウントアクティビティに対する警告や通知が行われます。

重大度: 低

データベースのログ記録は、有効にする必要がある

説明: このコントロールは、Amazon RDS の次のログが有効になっているかどうかを確認し、CloudWatch ログに送信します。

Oracle: (アラート、監査、トレース、リスナー)
PostgreSQL: (Postgresql、アップグレード)
MySQL: (Audit、Error、General、SlowQuery)
MariaDB: (Audit、Error、General、SlowQuery)
SQL Server: (エラー、エージェント)
Aurora: (Audit、Error、General、SlowQuery)
Aurora-MySQL: (Audit、Error、General、SlowQuery)
Aurora-PostgreSQL: (Postgresql、アップグレード)。 RDS データベースでは、関連するログが有効になっている必要があります。データベースのログ記録は、RDS に対して行われた要求の詳細なレコードを提供します。データベースログは、セキュリティとアクセスの監査に役立ち、可用性の問題を診断するのに便利です。

重大度: 中

Amazon Sage Maker ノートブックインスタンスの直接インターネットアクセスを無効にする

説明: Sage Maker ノートブックインスタンスでは、直接インターネットアクセスを無効にする必要があります。これにより、ノートブックインスタンスで 'DirectInternetAccess' フィールドが無効になっているかどうかをチェックできます。インスタンスには、VPC を構成する必要があります。既定では、VPC 経由のインターネットアクセスが [無効] になっているはずです。インターネットアクセスを有効にして、ノートブックからモデルをトレーニングまたはホスティングするには、VPC に NAT ゲートウェイが存在し、セキュリティグループで送信接続が許可されていることを確認してください。 Sage Maker 構成へのアクセスが承認されたユーザーのみに制限されていることを確認し、Sage Maker の設定とリソースを変更するようにユーザーの IAM アクセス許可を制限します。

重大度: 高

コンソールパスワードを持つすべての IAM ユーザーの初期ユーザー設定中は、アクセスキーを設定してはいけない

説明: AWS コンソールでは、アクセスキーを作成するためのチェックボックスがデフォルトで有効になっています。これにより、不必要なアクセスキーが多数生成されます。不必要な資格情報に加え、これらのキーの監査やローテーションにかかる不必要な管理作業も発生します。プロファイルの作成後にユーザーが追加の手順を実行する必要があると、アクセスキーが作業に必要であることを示す意図が強くなり、アカウントでアクセスキーが確立されると、そのキーが組織内のどこかで使用される可能性があることを示します。

重大度: 中

AWS Support でインシデントを管理するためのサポートロールが作成されていることを確認する

説明: AWS には、インシデントの通知と対応に使用できるサポートセンターと、テクニカルサポートとカスタマーサービスが用意されています。 IAM ロールを作成して、承認されたユーザーに対し、AWS Support でのインシデントの管理を許可します。アクセス制御の最小特権を実装する場合、IAM ロールには、AWS サポートでインシデントを管理するためにサポートセンターへのアクセスを許可するための適切な IAM ポリシーが必要です。

重大度: 低

アクセスキーが 90 日以下の頻度でローテーションされることを確認する

説明: アクセスキーは、アクセスキー ID とシークレットアクセスキーで構成されます。これは、AWS で行うプログラムによる要求に署名するために使用されます。 AWS ユーザーが AWS Command Line Interface (AWS CLI)、Tools for Windows PowerShell、AWS SDK から AWS へのプログラムによる呼び出し、または各 AWS サービスの API を使用した直接の HTTP 呼び出しを行うには、独自のアクセスキーが必要です。すべてのアクセスキーを定期的にローテーションすることをお勧めします。アクセスキーをローテーションすると、侵害されたアカウントまたは終了したアカウントに関連付けられているアクセスキーを使用する機会の期間が短縮されます。古いキーを使用してデータにアクセスできないようにするには、アクセスキーをローテーションする必要があります。このキーは、紛失、割れ、盗難にあった可能性があります。

重大度: 中

AWS Config がすべてのリージョンで有効になっていることを確認する

説明: AWS Config は、アカウント内でサポートされている AWS リソースの構成管理を実行し、ログファイルを配信する Web サービスです。記録される情報には、構成アイテム (AWS リソース)、構成アイテム間のリレーションシップ (AWS リソース)、リソース間の構成の変更が含まれます。すべてのリージョンで AWS Config を有効にすることをお勧めします。

AWS Config によってキャプチャされた AWS 構成アイテムの履歴を参照することで、セキュリティ分析、リソース変更追跡、コンプライアンス監査を実行することができます。

重大度: 中

すべてのリージョンで CloudTrail が有効になっていることを確認する

説明: AWS CloudTrail は、アカウントの AWS API 呼び出しを記録し、ログファイルを配信する Web サービスです。記録された情報には、API 呼び出し元の ID、API 呼び出しの時刻、API 呼び出し元の発信元 IP アドレス、要求パラメーター、AWS サービスによって返される応答要素が含まれます。 CloudTrail は、アカウントでの AWS API 呼び出しの履歴を提供します。これには、Management Console, SDK 経由で行われた API 呼び出し、およびより高レベルな AWS サービス (CloudFormation など) が含まれます。 CloudTrail によって生成される AWS API 呼び出し履歴を参照することで、セキュリティ分析、リソース変更追跡、コンプライアンス監査を実行することができます。さらに、

複数リージョンの証跡が存在することを確認すると、それ以外の場合は未使用のリージョンで発生する予期しないアクティビティが検出されます。
複数リージョンの証跡が存在することを確認すると、AWS グローバルサービスで生成されたイベントの記録をキャプチャするために、証跡に対して "グローバルサービスログ" が既定で有効になります。
複数リージョンの証跡の場合、すべての種類の読み取り/書き込みに対して管理イベントが構成されていることを確認すると、AWS アカウント内のすべてのリソースに対して実行される管理操作が確実に記録されます。

重大度: 高

90 日以上使用されていない資格情報が無効になっていることを確認する

説明: AWS IAM ユーザーは、パスワードやアクセスキーなど、さまざまな種類の資格情報を使用して AWS リソースにアクセスできます。 90 日以上で使用されていないすべての資格情報を削除または非アクティブ化することをお勧めします。不要な資格情報を無効または削除すると、侵害されたアカウントまたは破棄されたアカウントに関連付けられている資格情報を使用する機会の期間が短縮されます。

重大度: 中

IAM パスワードポリシーでのパスワードの有効期間が 90 日以下であることを確認する

説明: IAM パスワードポリシーでは、特定の日数が経過した後にパスワードをローテーションまたは期限切れにする必要があります。パスワードポリシーは、90 日以内にパスワードの有効期限を切らすことをお勧めします。パスワードの有効期間を短縮すると、ブルートフォースのログイン試行に対して、アカウント回復性が向上します。また、定期的なパスワード変更を必須にすると、次のシナリオで役立ちます。

パスワードは、知らないうちに盗まれたり、侵害されたりすることがあります。これは、システムのセキュリティ侵害、ソフトウェアの脆弱性、または内部の脅威によって起こることがあります。
特定の企業および政府機関の Web フィルターまたはプロキシサーバーでは、暗号化されている場合でもトラフィックをインターセプトして記録できます。
多くのユーザーは、仕事、電子メール、個人用など、多くのシステムで同じパスワードを使用します。
侵害されたエンドユーザーワークステーションには、キーストロークロガーが含まれています。

重大度: 低

IAM パスワードポリシーで、パスワードの再利用が禁止されていることを確認する

説明: IAM パスワードポリシーは、同じユーザーが特定のパスワードを再利用できないようにすることができます。パスワードポリシーは、パスワードの再利用を防ぐことをお勧めします。パスワードの再利用を禁止すると、ブルートフォースのログイン試行に対して、アカウント回復性が向上します。

重大度: 低

IAM パスワードポリシーで、1 つ以上の小文字の使用が必須であることを確認する

説明: パスワードポリシーの一部は、パスワードの複雑さの要件を適用するために使用されます。 IAM パスワードポリシーを使用して、パスワードが異なる文字セットで構成されていることを確認できます。パスワードポリシーには、少なくとも 1 つの小文字が必要です。パスワードの複雑さのポリシーを設定すると、ブルートフォースのログイン試行に対して、アカウント回復性が向上します。

重大度: 中

IAM パスワードポリシーで、1 つ以上の数字の使用が必須であることを確認する

説明: パスワードポリシーの一部は、パスワードの複雑さの要件を適用するために使用されます。 IAM パスワードポリシーを使用して、パスワードが異なる文字セットで構成されていることを確認できます。パスワードポリシーには少なくとも 1 つの数値が必要です。パスワードの複雑さのポリシーを設定すると、ブルートフォースのログイン試行に対して、アカウント回復性が向上します。

重大度: 中

IAM パスワードポリシーで、1 つ以上の記号の使用が必須であることを確認する

説明: パスワードポリシーの一部は、パスワードの複雑さの要件を適用するために使用されます。 IAM パスワードポリシーを使用して、パスワードが異なる文字セットで構成されていることを確認できます。パスワードポリシーには少なくとも 1 つのシンボルが必要です。パスワードの複雑さのポリシーを設定すると、ブルートフォースのログイン試行に対して、アカウント回復性が向上します。

重大度: 中

IAM パスワードポリシーで、1 つ以上の大文字の使用が必須であることを確認する

説明: パスワードポリシーの一部は、パスワードの複雑さの要件を適用するために使用されます。 IAM パスワードポリシーを使用して、パスワードが異なる文字セットで構成されていることを確認できます。パスワードポリシーには、少なくとも 1 つの大文字が必要です。パスワードの複雑さのポリシーを設定すると、ブルートフォースのログイン試行に対して、アカウント回復性が向上します。

重大度: 中

IAM パスワードポリシーで、14 文字以上の長さが必須であることを確認する

説明: パスワードポリシーの一部は、パスワードの複雑さの要件を適用するために使用されます。 IAM パスワードポリシーに従うと、指定された長さ以上のパスワードが作成されます。パスワードポリシーでは、パスワードの最小長が "14" である必要があります。パスワードの複雑さのポリシーを設定すると、ブルートフォースのログイン試行に対して、アカウント回復性が向上します。

重大度: 中

コンソールパスワードを持つすべての IAM ユーザーに対して多要素認証 (MFA) が有効になっていることを確認する

説明: 多要素認証 (MFA) により、ユーザー名とパスワードの上に保護レイヤーが追加されます。 MFA を有効にすると、ユーザーが AWS Web サイトにサインインすると、ユーザー名とパスワード、および AWS MFA デバイスからの認証コードの入力を求められます。コンソールパスワードを持つすべてのアカウントに対して MFA を有効にすることをお勧めします。 MFA を有効にすると、時間を区別するキーを出力し、資格情報を認識するデバイスを保持するためのプリンシパルが必要になるため、コンソールアクセスのセキュリティが強化されます。

重大度: 中

GuardDuty は、有効にする必要がある

説明: 侵入に対する追加の保護を提供するには、AWS アカウントとリージョンで GuardDuty を有効にする必要があります。

GuardDuty は、すべての環境に対して完全なソリューションとは言えない場合があります。

重大度: 中

ハードウェア MFA は、"root" アカウントに対して有効になっている必要がある

説明: ルートアカウントは、アカウント内で最も特権のあるユーザーです。 MFA を使用すると、ユーザー名とパスワードの場合と比べ、保護層が強化されます。 MFA が有効な場合、ユーザーが AWS Web サイトにサインインすると、ユーザー名とパスワードに加え、AWS MFA デバイスに表示された認証コードの入力が求められます。レベル 2 では、ハードウェア MFA を使用してルートアカウントを保護することをお勧めします。ハードウェア MFA の場合、攻撃対象となる領域が、仮想 MFA よりも小さくなります。たとえば、ハードウェア MFA では、仮想 MFA が存在するモバイルスマートフォンによって導入される攻撃対象は、問題とはなりません。多くのアカウントで MFA にハードウェアを使用すると、物流デバイス管理の問題が発生する可能性があります。その場合は、このレベル 2 の推奨事項を、最高レベルのセキュリティアカウントに絞って実装することを検討してください。その後、残りのアカウントに対して、レベル 1 の推奨事項を適用してください。

重大度: 低

IAM 認証は、RDS クラスターに対して構成する必要がある

説明: このコントロールは、RDS DB クラスターで IAM データベース認証が有効になっているかどうかを確認します。 IAM データベース認証を使用すると、データベースインスタンスへのパスワードなしの認証が可能になります。この認証では、認証トークンが使用されます。データベースとのネットワークトラフィックの送受信は、SSL を使用して暗号化されます。詳細については、Amazon Aurora ユーザーガイドの IAM データベース認証についてのページを参照してください。

重大度: 中

IAM 認証は、RDS インスタンスに対して構成する必要がある

説明: このコントロールは、RDS DB インスタンスで IAM データベース認証が有効になっているかどうかを確認します。 IAM データベース認証では、データベースインスタンスへの認証に、パスワードではなく、認証トークンを使用できます。データベースとのネットワークトラフィックの送受信は、SSL を使用して暗号化されます。詳細については、Amazon Aurora ユーザーガイドの IAM データベース認証についてのページを参照してください。

重大度: 中

IAM カスタマーマネージドポリシーでは、すべての KMS キーに対する暗号化解除アクションを許可しないようにする必要がある

説明: IAM カスタマーマネージドポリシーの既定のバージョンで、プリンシパルがすべてのリソースで AWS KMS 復号化アクションを使用できるかどうかを確認します。このコントロールでは、自動化された推論エンジン Zelkova を使用して、AWS アカウント全体でシークレットへの広範なアクセスを許可する可能性があるポリシーについて検証し、警告します。すべての KMS キーで "kms: Decrypt" または "kms: ReEncryptFrom" アクションが許可されている場合、このコントロールは失敗します。このコントロールによって、アタッチされているかいないかにかかわらず、カスタマーマネージドポリシーが評価されます。インラインポリシーや AWS マネージドポリシーは確認されません。 AWS KMS では、KMS キーを使用できるユーザーを制御し、暗号化されたデータにアクセスすることができます。 IAM ポリシーでは、ID (ユーザー、グループ、またはロール) によって、どのアクションが、どのリソースに対して実行されるかが定義されます。セキュリティのベストプラクティスに従い、AWS では、最小限の特権を許可することをお勧めします。つまり、"kms:Decrypt" または "kms:ReEncryptFrom" のアクセス許可のみを、タスクの実行が要求されるキーのみに対して、ID に許可する必要があります。それ以外の場合、ユーザーはデータに適さないキーを使用する可能性があります。すべてのキーについてアクセス許可を付与する代わりに、暗号化されたデータにアクセスするためにユーザーが必要とするキーの最小限のセットを決定します。次に、ユーザーに対し、それらのキーのみの使用を許可するポリシーを作成します。たとえば、すべての KMS キーに対して "kms: Decrypt" アクセス許可を許可しないでください。代わりに、アカウントの特定のリージョンのキーに対してのみ "kms: Decrypt" を許可します。最小限の特権を採用することで、データが意図せずに公開されるリスクを軽減することができます。

重大度: 中

作成する IAM カスタマーマネージドポリシーでは、サービスに対するワイルドカードアクションを許可しないようにする必要がある

説明: このコントロールは、作成する IAM ID ベースのポリシーに、* ワイルドカードを使用して任意のサービスのすべてのアクションに対するアクセス許可を付与する Allow ステートメントがあるかどうかを確認します。ポリシーステートメントに 'Effect': 'Allow' と 'Action': 'Service:*' が含まれている場合、コントロールは失敗します。たとえば、ポリシー内に次のポリシーステートメントがある場合、結果は失敗となります。

'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:*',
  'Resource': '*'
}

'Effect': 'Allow' と 'NotAction': 'service:' を使用すると、コントロールも失敗します。その場合、NotAction 要素は、NotAction で指定されたアクションを除き、AWS サービス内のすべてのアクションへのアクセスを提供します。このコントロールは、カスタマーマネージド IAM ポリシーにのみ適用されます。AWS によって管理される IAM ポリシーには適用されません。AWS サービスにアクセス許可を割り当てるときは、IAM ポリシーで許可されている IAM アクションのスコープを設定することが重要です。IAM アクションは、必要なアクションのみに制限する必要があります。これにより、最小限の特権のアクセス許可をプロビジョニングできます。ポリシーがアクセス許可を必要としない IAM プリンシパルにアタッチされている場合、過度に制限されたポリシーが特権エスカレーションにつながる可能性があります。場合によっては、DescribeFlowLogs や DescribeAvailabilityZones など、似たプレフィックスを持つ IAM アクションを許可することが必要になる場合があります。このような承認されたケースでは、サフィックス付きワイルドカードを共通プレフィックスに追加できます。たとえば、ec2:Describe。

このコントロールは、プレフィックス付き IAM アクションとサフィックス付きワイルドカードを使用する場合に成功します。たとえば、ポリシー内に次のステートメントがある場合、結果は成功となります。

 'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:Describe*',
  'Resource': '*'
}

この方法で関連する IAM アクションをグループ化すると、IAM ポリシーのサイズ制限を超過しないようにすることができます。

重大度: 低

IAM ポリシーは、グループまたはロールのみにアタッチする必要がある

説明: 既定では、IAM ユーザー、グループ、ロールは AWS リソースにアクセスできなくなります。 IAM ポリシーは、ユーザー、グループ、またはロールに特権を付与するための手段です。 IAM ポリシーは、ユーザーではなくグループとロールに直接適用することをお勧めします。グループまたはロールレベルで特権を割り当てると、ユーザー数が増えるにつれて、アクセス管理の複雑さが軽減されます。アクセス管理の複雑さを軽減すると、プリンシパルが誤って過剰な特権を受け取ったり保持したりする機会が減る可能性もあります。

重大度: 低

完全な ":" 管理特権を許可する IAM ポリシーが作成されないようにする必要がある

説明: IAM ポリシーは、ユーザー、グループ、またはロールに権限を付与する手段です。最小限の特権を付与し、タスクの実行に必要なアクセス許可のみを付与することが推奨され、標準的なセキュリティのアドバイスと見なされます。ユーザーが実行する必要がある操作を決定し、完全な管理特権を許可するのではなく、ユーザーがそれらのタスクのみを実行できるようにするポリシーを作成します。最初に寛大すぎるアクセス許可を付与して、後で厳格化するよりも、最小限のアクセス許可から始めて、必要に応じて追加のアクセス許可を付与していく方が安全です。ユーザーが実行する必要がある最低限のアクセス許可に制限するのではなく、完全な管理特権を付与する場合は、望ましくない可能性のあるアクションにリソースが公開されてしまいます。 "Effect": "Allow" および "Action": "" over "Resource": "" が含まれる IAM ポリシーは、削除する必要があります。

重大度: 高

すべての KMS キーに暗号化解除アクションを許可する IAM インラインポリシーを IAM プリンシパルに指定しないようにする必要がある

説明: IAM ID (ロール、ユーザー、またはグループ) に埋め込まれているインラインポリシーが、すべての KMS キーに対する AWS KMS 復号化アクションを許可するかどうかを確認します。このコントロールでは、自動化された推論エンジン Zelkova を使用して、AWS アカウント全体でシークレットへの広範なアクセスを許可する可能性があるポリシーについて検証し、警告します。インラインポリシー内のすべての KMS キーで kms:Decrypt または kms:ReEncryptFrom アクションが許可されている場合、この制御は失敗します。 AWS KMS では、KMS キーを使用できるユーザーを制御し、暗号化されたデータにアクセスすることができます。 IAM ポリシーでは、ID (ユーザー、グループ、またはロール) によって、どのアクションが、どのリソースに対して実行されるかが定義されます。セキュリティのベストプラクティスに従い、AWS では、最小限の特権を許可することをお勧めします。つまり、必要なアクセス許可のみを、タスクの実行に必要なキーについてのみ、ID に付与する必要があります。それ以外の場合、ユーザーはデータに適さないキーを使用する可能性があります。すべてのキーについてアクセス許可を付与する代わりに、暗号化されたデータにアクセスするためにユーザーが必要とするキーの最小限のセットを決定します。次に、ユーザーに対し、それらのキーのみの使用を許可するポリシーを作成します。たとえば、すべての KMS キー kms:Decrypt アクセス許可を許可しないでください。代わりに、アカウントでは、特定のリージョン内のキーに対してのみ許可します。最小限の特権を採用することで、データが意図せずに公開されるリスクを軽減することができます。

重大度: 中

Lambda 関数は、パブリックアクセスを制限する必要がある

説明: ラムダ関数のリソースベースのポリシーでは、パブリックアクセスを制限する必要があります。この推奨事項では、内部プリンシパルによるアクセスは確認されません。最小限の特権があるリソースベースのポリシーを使用することで、関数へのアクセスを、承認されたプリンシパルに制限されるようにします。

重大度: 高

MFA は、すべての IAM ユーザーに対して有効になっている必要がある

説明: すべての IAM ユーザーで多要素認証 (MFA) が有効になっている必要があります。

重大度: 中

MFA は、"root" アカウントに対して有効になっている必要がある

説明: ルートアカウントは、アカウント内で最も特権のあるユーザーです。 MFA を使用すると、ユーザー名とパスワードの場合と比べ、保護層が強化されます。 MFA が有効な場合、ユーザーが AWS Web サイトにサインインすると、ユーザー名とパスワードに加え、AWS MFA デバイスに表示された認証コードの入力が求められます。ルートアカウントに仮想 MFA を使用する場合は、使用するデバイスが個人用デバイスではないことをお勧めします。代わりに、専用モバイルデバイス (タブレットまたはスマートフォン) を使用して、個別の個人用デバイスとは別に、課金やセキュリティ保護が引き続き行われるように管理します。この教訓により、デバイスの損失、デバイスのトレードイン、またはデバイスを所有している個人が会社によって雇用されなくなった場合に、MFA へのアクセスが失われるリスクが軽減されます。

重大度: 低

IAM ユーザーのパスワードポリシーには、強力な構成が必要である

説明: IAM ユーザーのアカウントパスワードポリシーで次の最小構成が使用されているかどうかを確認します。

RequireUppercaseCharacters- パスワードに少なくとも 1 つの大文字が必要です。 (既定値 = true)
RequireLowercaseCharacters - パスワードに少なくとも 1 つの小文字が必要です。 (既定値 = true)
RequireNumbers - パスワードに少なくとも 1 つの数値が必要です。 (既定値 = true)
MinimumPasswordLength- パスワードの最小長。 (既定値 = 7 以上)
PasswordReusePrevention - 再利用を許可する前のパスワードの数。 (既定値 = 4)
MaxPasswordAge - パスワードの有効期限が切れるまでの日数。 (既定値 = 90)

重大度: 中

AWS アカウントの非アクティブな ID のアクセス許可を取り消す必要がある

説明: Microsoft Defender for Cloud は、過去 45 日間に AWS アカウント内のリソースに対して何もアクションを実行していない ID を検出しました。クラウド環境の攻撃対象領域を減らすために、非アクティブな ID のアクセス許可を取り消すことが推奨されます。

重大度: 中

root アカウントアクセスキーは、存在してはならない

説明: ルートアカウントは、AWS アカウントで最も特権のあるユーザーです。 AWS アクセスキーを使用すると、特定の AWS アカウントにプログラムでアクセスできます。ルートアカウントに関連付けられているすべてのアクセスキーを削除することをお勧めします。 root アカウントに関連付けられているアクセスキーを削除すると、アカウントが侵害される可能性があるベクターが制限されます。さらに、root アクセスキーを削除すると、最小限の特権を持つロールベースのアカウントの作成と使用が促進されます。

重大度: 高

S3 ブロックパブリックアクセスの設定は、有効にする必要がある

説明: S3 バケットに対して [パブリックアクセスのブロック] 設定を有効にすると、機密データの漏洩を防ぎ、悪意のあるアクションからバケットを保護できます。

重大度: 中

S3 ブロックパブリックアクセスの設定は、バケットレベルで有効にする必要がある

説明: このコントロールは、S3 バケットにバケットレベルのパブリックアクセスブロックが適用されているかどうかを確認します。次のいずれかの設定が false に設定されている場合、このコントロールは失敗します。

ignorePublicAcls
blockPublicPolicy
blockPublicAcls
restrictPublicBuckets S3 バケットレベルでパブリックアクセスをブロックすると、オブジェクトがパブリックアクセスを持たないようにするための制御が提供されます。パブリックアクセスは、アクセスコントロールリスト (ACL)、バケットポリシー、またはそれらの両方を介して、バケットとオブジェクトに付与されます。 S3 バケットをパブリックにアクセス可能にする予定がなければ、バケットレベルの Amazon S3 ブロックパブリック機能を構成する必要があります。

重大度: 高

S3 バケットパブリック読み取りアクセス権は、削除する必要がある

説明: S3 バケットへのパブリック読み取りアクセスを削除すると、データを保護し、データ侵害を防ぐことができます。

重大度: 高

S3 バケットパブリック書き込みアクセス権は、削除する必要がある

説明: S3 バケットへのパブリック書き込みアクセスを許可すると、費用でデータを格納したり、身代金のためにファイルを暗号化したり、バケットを使用してマルウェアを操作したりするなどの悪意のあるアクションに対して脆弱になる可能性があります。

重大度: 高

シークレットマネージャーのシークレットでは、自動ローテーションを有効にする必要がある

説明: このコントロールは、AWS Secrets Manager に格納されているシークレットが自動ローテーションで構成されているかどうかを確認します。 Secrets Manager は、組織のセキュリティ体制の改善に役立ちます。シークレットには、データベースの資格情報、パスワード、サードパーティの API キーが含まれます。 Secrets Manager を使用すると、シークレットを中心に格納したり、シークレットを自動的に暗号化したりすることに加え、シークレットへのアクセスを制御したり、シークレットを安全かつ自動的にローテーションしたりすることができます。 Secrets Manager では、シークレットのローテーションが可能です。ローテーションを使用すると、長期シークレットを短期シークレットに置き換えることができます。シークレットをローテーションすることで、侵害されたシークレットを未承認ユーザーが使用できる期間が制限されます。このような理由により、シークレットを頻繁にローテーションする必要があります。ローテーションの詳細については、AWS Secrets Manager ユーザーガイドの「Rotating your AWS Secrets Manager secrets」 (AWS Secrets Manager シークレットのローテーション) を参照してください。

重大度: 中

停止した EC2 インスタンスは、指定した期間の後で、削除する必要がある

説明: このコントロールは、許可された日数を超える EC2 インスタンスが停止されているかどうかを確認します。 EC2 インスタンスは、許可された最大期間 (既定では 30 日間) よりも長く停止している場合、このチェックに失敗します。失敗の結果は、EC2 インスタンスが非常に長い期間実行されていないことを示します。これにより、EC2 インスタンスがアクティブに維持されていない (分析、修正プログラムの適用、更新) ため、セキュリティリスクが発生します。後で起動した場合、適切なメンテナンスが行わないと、AWS 環境で予期しない問題が発生する可能性があります。 EC2 インスタンスを非実行状態で一定の時間にわたって安全に維持するには、定期的に起動してメンテナンスを行い、メンテナンス後に停止します。このプロセスが自動化されるのが理想的です。

重大度: 中

AWS 環境で未使用の ID を削除する必要がある (プレビュー)

説明: 非アクティブな ID は、過去 90 日間にリソースに対して何もアクションを実行していない人間および非人間のエンティティです。 AWS アカウントでリスクの高いアクセス許可を持つ非アクティブな IAM ID は、そのまま残しておくと攻撃を受けやすく、組織は資格情報の悪用や悪用を受け入れる可能性があります。未使用の ID を事前に検出して応答すると、承認されていないエンティティが AWS リソースにアクセスするのを防ぐことができます。

重大度: 中

GCP ID とアクセスに関する推奨事項

暗号化キーに 3 人を超えるユーザーを含めてはならない

説明: この推奨事項は、キーリングの IAM ポリシーを評価します。プロジェクト、組織、およびクラウド KMS キーを使用してデータを暗号化、暗号化解除、または署名できるロールを持つプリンシパルを取得します。ロール/所有者、ロール/cloudkms.cryptoKeyEncrypterDecrypter、roles/cloudkms.cryptoKeyEncrypter、roles/cloudkms.cryptoKeyDecrypter、roles/cloudkms.signer、roles/cloudkms.signerVerifier。

重大度: 中

プロジェクトに対して API キーが作成されていないことを確認する

説明: キーは、ブラウザー内など、パブリックに表示したり、キーが存在するデバイスでアクセスしたりできるため、安全ではありません。代わりに標準認証フローを使用することをお勧めします。

API キーの使用に関連するセキュリティリスクは、次のとおりです。

API キーは単純な暗号化された文字列です
API キーは、API 要求を行っているユーザーまたはアプリケーションを識別しません
API キーは通常、クライアントからアクセスできるため、API キーを簡単に検出して盗むことができます

API キーを使用する場合のセキュリティリスクを回避するには、代わりに標準認証フローを使用することをお勧めします。

重大度: 高

アプリケーションがアクセスを必要とする API のみに API キーが制限されていることを確認する

説明: API キーは、ブラウザー内など、パブリックに表示したり、キーが存在するデバイスでアクセスしたりできるため、安全ではありません。アプリケーションで必要な API のみを使用 (呼び出し) するように API キーを制限することをお勧めします。

API キーの使用に関連するセキュリティリスクは、次のとおりです。

API キーは単純な暗号化された文字列です
API キーは、API 要求を行っているユーザーまたはアプリケーションを識別しません
API キーは通常、クライアントからアクセスできるため、API キーを簡単に検出して盗むことができます

これらの潜在的なリスクを考慮し、Google では API キーの代わりに標準認証フローを使用することを推奨しています。ただし、API キーの方が適している限定的なケースがあります。たとえば、Google Cloud Translation API を使用する必要があるが、バックエンドサーバーが不要なモバイルアプリケーションがある場合、API キーはその API に対する認証を行う最も簡単な方法です。

最小限の権限を提供して攻撃面を削減するために、API キーをアプリケーションが必要な API の使用 (呼び出し) のみに制限できます。

重大度: 高

指定されたホストとアプリのみで使用されるように API キーが制限されていることを確認する

説明: 無制限のキーは、ブラウザー内など、パブリックに表示したり、キーが存在するデバイスでアクセスしたりできるため、安全ではありません。信頼されたホスト、HTTP 参照元、アプリに API キーの使用を制限することをお勧めします。

API キーの使用に関連するセキュリティリスクは、次のとおりです。

API キーは単純な暗号化された文字列です
API キーは、API 要求を行っているユーザーまたはアプリケーションを識別しません
API キーは通常、クライアントからアクセスできるため、API キーを簡単に検出して盗むことができます

攻撃ベクトルを減らすために、API キーは信頼できるホスト、HTTP 参照元、およびアプリケーションのみに制限できます。

重大度: 高

API キーが 90 日ごとにローテーションされていることを確認する

説明: API キーは 90 日ごとにローテーションすることをお勧めします。

API キーの使用に関連するセキュリティリスクを以下にリストします。

API キーは単純な暗号化された文字列です
API キーは、API 要求を行っているユーザーまたはアプリケーションを識別しません
API キーは通常、クライアントからアクセスできるため、API キーを簡単に検出して盗むことができます

これらの潜在的なリスクのため、Google では API キーの代わりに標準認証フローを使用することを推奨しています。ただし、API キーの方が適している限定的なケースがあります。たとえば、Google Cloud Translation API を使用する必要があるが、バックエンドサーバーが不要なモバイルアプリケーションがある場合、API キーはその API に対する認証を行う最も簡単な方法です。

キーが盗まれた後は有効期限が切れません。つまり、プロジェクト所有者がキーを取り消すか再生成しない限り、無期限に使用される可能性があります。 API キーをローテーションさせることで、侵害または終了されたアカウントに関連付けられたアクセスキーが使用される可能性を削減できます。

API キーをローテーションして、紛失、解読、盗難にあった古いキーでデータにアクセスできないようにする必要があります。

重大度: 高

KMS 暗号化キーが 90 日以内にローテーションされることを確認する

説明: Google Cloud キー管理サービスは、便利でエレガントなアクセス制御管理のために設計された階層構造に暗号化キーを格納します。ローテーションスケジュールの形式は、使用されるクライアントライブラリによって異なります。 gcloud コマンドラインツールの場合、次の回転時間は "ISO" または "RFC3339" 形式である必要があり、回転期間は "INTEGER[UNIT]" の形式である必要があります。単位は秒、分 (m)、時間 (h)、または日 (d) のいずれかになります。キーのローテーション期間と開始時刻を設定します。キーは、指定された "ローテーション期間" で作成できます。これは、新しいキーバージョンが自動的に生成されてからの時間です。キーは、次回のローテーション時間を指定して作成することもできます。キーは、特定の目的に使用される "暗号化キー" を表す名前付きオブジェクトです。キーマテリアル ("暗号化" に使用される実際のビット) は、新しいキーバージョンが作成されると時間の経過と同時に変化する可能性があります。キーは、"データのコーパス" を保護するために使用されます。ファイルのコレクションは同じキーで暗号化でき、そのキーに対する "復号化" アクセス許可を持つユーザーはそれらのファイルを復号化できます。そのため、"ローテーション期間" が特定の時刻に設定されていることを確認する必要があります。

重大度: 中

プロジェクト所有権の割り当て変更に関して、ログメトリックフィルターとアラートが存在することを確認する

説明: ユーザー/サービスアカウントへの不要なプロジェクト所有権の割り当てや、プロジェクトとリソースの不正使用を防ぐために、すべての "ロール/所有者" 割り当てを監視する必要があります。プリミティブロール "ロール/所有者" にロールが割り当てられているメンバー (ユーザー/サービスアカウント) は、プロジェクト所有者です。プロジェクト所有者には、ロールが属するプロジェクトに対するすべての特権があります。これらの概要を次に示します。

プロジェクト内のすべての GCP サービスに対するすべてのビューアーのアクセス許可
プロジェクト内のすべての GCP サービスの状態を変更するアクションのアクセス許可
プロジェクトとプロジェクト内のすべてのリソースのロールとアクセス許可を管理する
プロジェクトの課金を設定します。所有者ロールをメンバー (user/Service-Account) に付与すると、そのメンバーは ID およびアクセス管理 (IAM) ポリシーを変更できます。そのため、メンバーが IAM ポリシーを管理する正当な目的を持っている場合にのみ、所有者ロールを付与します。これは、プロジェクトの IAM ポリシーに機密性の高いアクセス制御データが含まれているためです。 IAM ポリシーの管理を許可されるユーザーのセットを最小限にすることで、必要な監査が簡略化されます。プロジェクト所有権には、プロジェクトに対する最高レベルの特権があります。プロジェクトリソースの不正使用を回避するには、上記のプロジェクト所有権の割り当て/変更アクションを監視し、関係する受信者に警告する必要があります。
プロジェクト所有権の招待の送信
ユーザーによるプロジェクト所有権の招待の承諾/拒否
ユーザー/サービスアカウントへの role\Owner の追加
ユーザー/サービスアカウントの削除 role\Owner

重大度: 低

プロジェクトで oslogin が有効になっていることを確認する

説明: OS ログインを有効にすると、SSH 証明書が IAM ユーザーにバインドされ、効果的な SSH 証明書管理が容易になります。 osLogin を有効にすると、インスタンスへの接続に使用される SSH キーが IAM ユーザーにマップされるようになります。 IAM ユーザーへのアクセスを取り消すと、その特定のユーザーに関連付けられているすべての SSH キーが取り消されます。これは、一元化された自動化された SSH キーペア管理を容易にします。これは、侵害された SSH キーペアへの対応や、外部/サードパーティ/ベンダーユーザーの失効などのケースの処理に役立ちます。プロジェクトが異常になる原因となるインスタンスを確認するには、「すべてのインスタンスに対してオスロギンが有効になっていることを確認する」の推奨事項を参照してください。

重大度: 中

すべてのインスタンスで oslogin が有効になっていることを確認する

重大度: 中

プロジェクトのすべてのサービスとすべてのユーザーに対して、クラウド監査ログが正しく構成されていることを確認する

説明: クラウド監査ログは、すべての管理者アクティビティを追跡し、ユーザーデータへの読み取り、書き込みアクセスを追跡するように構成することをお勧めします。

クラウド監査ログには、プロジェクト、フォルダー、組織ごとに 2 つの監査ログ (管理アクティビティとデータアクセス) が保持されます。

管理アクティビティログには、リソースの構成またはメタデータを変更する API 呼び出しやその他の管理アクションのログエントリが含まれます。
管理者アクティビティ監査ログはすべてのサービスで有効になっており、構成することはできません。
データアクセス監査ログには、ユーザーが提供したデータを作成、変更、または読み取る API 呼び出しが記録されます。これらは既定で無効になっており、有効にする必要があります。

データアクセス監査ログ情報には、次の 3 種類があります。

管理読み取り: メタデータまたは構成情報を読み取る操作を記録します。管理者アクティビティ監査ログには、無効にできないメタデータと構成情報の書き込みが記録されます。
データ読み取り: ユーザーが提供したデータを読み取る操作を記録します。
データ書き込み: ユーザーが提供したデータを書き込む操作を記録します。

次のような方法で有効な既定の監査構成を構成することをお勧めします。

ログの種類は、DATA_READ (ユーザーアクティビティの追跡をログに記録するため) とDATA_WRITES (変更をログに記録したり、ユーザーデータを改ざんしたりするため) に設定されます。
監査構成は、データアクセス監査ログ機能でサポートされているすべてのサービスに対して有効になっています。
すべてのユーザーについてログをキャプチャする必要があります。つまり、監査構成セクションに除外されたユーザーは存在しません。これにより、監査構成のオーバーライドが要件と矛盾しないようにします。

重大度: 中

クラウド KMS 暗号化キーが匿名またはパブリックにアクセスできないようにする

説明: Cloud KMS 暗号化キーの IAM ポリシーでは、匿名またはパブリックアクセスを制限することをお勧めします。 "allUsers" または "allAuthenticatedUsers" にアクセス許可を付与すると、すべてのユーザーがデータセットにアクセスできるようになります。その場所に機密データが格納されている場合、このようなアクセスは望ましくない可能性があります。この場合は、クラウド KMS 暗号化キーへの匿名またはパブリックアクセスが許可されていないことを確認します。

重大度: 高

説明: Gmail アカウントなどの個人用アカウントではなく、会社のログイン資格情報を使用します。クラウドプラットフォームリソースへの可視性、監査、およびアクセスの制御を強化するために、フルマネージドの企業 Google アカウントを使用することをお勧めします。個人用アカウントなど、ユーザーの組織外に基づく Gmail アカウントは、ビジネス目的で使用しないでください。

重大度: 高

IAM ユーザーに、プロジェクトレベルでサービスアカウントユーザーまたはサービスアカウントトークン作成者のロールが割り当てられていないことを確認する

説明: プロジェクトレベルでユーザーにロールを割り当てるのではなく、特定のサービスアカウントのユーザーに "サービスアカウントユーザー (iam.serviceAccountUser)" ロールと "サービスアカウントトークン作成者 (iam.serviceAccountTokenCreator)" ロールを割り当てることをお勧めします。サービスアカウントは、個々のエンドユーザーではなく、アプリケーションまたは仮想マシン (VM) に属する特別な Google アカウントです。アプリケーション/VM インスタンスでは、サービスアカウントを使用してサービスの Google API を呼び出し、ユーザーが直接関与しないようにします。サービスアカウントは、ID であることに加えて、IAM ポリシーがアタッチされているリソースです。これらのポリシーによって、サービスアカウントを使用できるユーザーが決まります。 App Engine と Compute Engine のインスタンス (App Engine Deployer や Compute Instance 管理など) を更新する IAM ロールを持つユーザーは、これらのインスタンスの実行に使用されるサービスアカウントとしてコードを効果的に実行し、サービスアカウントがアクセスできるすべてのリソースに間接的にアクセスできます。同様に、コンピューティングエンジンインスタンスへの SSH アクセスでは、そのインスタンス/サービスアカウントとしてコードを実行する機能も提供される場合があります。ビジネスニーズに基づいて、1 つのプロジェクトに対して複数のユーザー管理サービスアカウントが構成されている場合もあります。プロジェクトのユーザーに "iam.serviceAccountUser" ロールまたは "iam.serviceAserviceAccountTokenCreatorccountUser" ロールを付与すると、今後作成される可能性のあるサービスアカウントを含め、プロジェクト内のすべてのサービスアカウントへのアクセス権がユーザーに付与されます。これにより、サービスアカウントと対応する "コンピューティングエンジンインスタンス" を使用して特権が昇格される可能性があります。"最小限の特権" のベストプラクティスを実装するには、IAM ユーザーにプロジェクトレベルで "サービスアカウントユーザー" ロールまたは "サービスアカウントトークン作成者" ロールを割り当てることはできません。代わりに、これらのロールを特定のサービスアカウントのユーザーに割り当てて、そのユーザーにサービスアカウントへのアクセス権を付与する必要があります。 "サービスアカウントユーザー" を使用すると、ユーザーはサービスアカウントを実行時間の長いジョブサービスにバインドできます。一方、"サービスアカウントトークン作成者" ロールを使用すると、ユーザーはサービスアカウントの ID を直接偽装 (またはアサート) できます。

重大度: 中

説明: KMS 関連ロールをユーザーに割り当てるときに、"職務の分離" の原則を適用することをお勧めします。組み込み/定義済みの IAM ロール "Cloud KMS Admin" を使用すると、ユーザー/ID はサービスアカウントを作成、削除、管理できます。組み込み/定義済みの IAM ロール Cloud KMS CryptoKey Encrypter/Decrypter を使用すると、ユーザー/ID (関連するリソースに対する適切な特権を持つ) は、暗号化キーを使用して保存データを暗号化および復号化できます。組み込み/定義済みの IAM ロール Cloud KMS CryptoKey Encrypter を使用すると、ユーザー/ID (関連するリソースに対する適切な特権を持つ) が、暗号化キーを使用して保存データを暗号化できます。組み込み/定義済みの IAM ロール Cloud KMS Crypto Key Decrypter を使用すると、ユーザー/ID (関連するリソースに対する適切な特権を持つ) は、暗号化キーを使用して保存データの暗号化を解除できます。職務の分離は、1 人の個人が悪意のあるアクションを完了するために必要なすべてのアクセス許可を持っていないことを保証するという概念です。 Cloud KMS では、これは、ユーザーが通常アクセス権を持つべきではないデータへのアクセスと復号化にキーを使用するなどのアクションである可能性があります。職務の分離は、一般的に大規模な組織で使用される業務管理であり、セキュリティまたはプライバシーのインシデントやエラーを回避するために役立ちます。ベストプラクティスと見なされます。 Cloud KMS 管理者と、 Cloud KMS CryptoKey Encrypter/Decrypter、 Cloud KMS CryptoKey Encrypter、 Cloud KMS CryptoKey Decrypter ロールを同時に割り当てる必要があるユーザーはいません。

重大度: 高

説明: サービスアカウント関連のロールをユーザーに割り当てるときに、"職務の分離" の原則を適用することをお勧めします。組み込み/定義済みの IAM ロール "サービスアカウント管理者" を使用すると、ユーザー/ID はサービスアカウントを作成、削除、管理できます。組み込み/定義済みの IAM ロール "サービスアカウントユーザー" を使用すると、(Compute Engine および App Engine に対する適切な特権を持つ) ユーザー/ID が、サービスアカウントを Apps/Compute インスタンスに割り当てることができます。職務の分離は、1 人の個人が悪意のあるアクションを完了するために必要なすべてのアクセス許可を持っていないことを保証するという概念です。 Cloud IAM - サービスアカウントでは、これは、ユーザーが通常アクセスできないリソースにアクセスするためにサービスアカウントを使用するなどのアクションである可能性があります。職務の分離は、一般的に大規模な組織で使用される業務管理であり、セキュリティまたはプライバシーのインシデントやエラーを回避するために役立ちます。ベストプラクティスと見なされます。 "サービスアカウント管理" ロールと "サービスアカウントユーザー" ロールを 1 人のユーザーに同時に割り当てないでください。

重大度: 中

サービスアカウントに管理特権がないことを確認する

説明: サービスアカウントは、個々のエンドユーザーではなく、アプリケーションまたは VM に属する特別な Google アカウントです。アプリケーションでは、サービスアカウントを使用してサービスの Google API を呼び出し、ユーザーが直接関与しないようにします。 ServiceAccount には管理者アクセスを使用しないことをお勧めします。サービスアカウントは、割り当てられたロールによって決定できる、リソース (アプリケーションまたは VM) のサービスレベルのセキュリティを表します。管理権限を持つ ServiceAccount を登録すると、割り当てられたアプリケーションまたは VM にフルアクセスできます。 ServiceAccount アクセスの所有者は、削除、更新、設定の変更などの重要なアクションをユーザーの操作なしで実行できます。このため、サービスアカウントに管理権限を付与しないことをお勧めします。

重大度: 中

すべてのログエントリでシンクが構成されていることを確認する

説明: すべてのログエントリのコピーをエクスポートするシンクを作成することをお勧めします。これは、複数のプロジェクトからログを集計し、セキュリティ情報イベント管理 (SIEM) にエクスポートするのに役立ちます。ログエントリは Stackdriver ログに保持されます。ログを集計するには、それらを SIEM にエクスポートします。それらを長く保つために、ログシンクを設定することをお勧めします。エクスポートするには、エクスポートするログエントリを選択するフィルターを記述し、Cloud Storage、BigQuery、または Cloud Pub/Sub で宛先を選択する必要があります。フィルターと宛先は、シンクと呼ばれるオブジェクトに保持されます。すべてのログエントリがシンクにエクスポートされるようにするには、シンクに対してフィルターが構成されていないことを確認します。シンクは、プロジェクト、組織、フォルダー、課金アカウントに作成できます。

重大度: 低

監査構成の変更のためのログメトリックフィルターとアラートが存在することを確認する

説明: Google Cloud Platform (GCP) サービスは、監査ログエントリを管理者アクティビティログとデータアクセスログに書き込みます。エントリは、GCP プロジェクト内の "誰が何を、どこで、いつ行ったか" という質問に答えるのに役立ちます。クラウド監査ログの記録情報には、API 呼び出し元の ID、API 呼び出しの時刻、API 呼び出し元の発信元 IP アドレス、要求パラメーター、GCP サービスによって返される応答要素が含まれます。クラウド監査ログには、コンソール、SDK、コマンドラインツール、その他の GCP サービスを介して行われた API 呼び出しなど、アカウントの GCP API 呼び出しの履歴が提供されています。クラウド監査ログによって生成される管理者アクティビティとデータアクセスログにより、セキュリティ分析、リソース変更の追跡、コンプライアンス監査が可能になります。監査構成の変更に対するメトリックフィルターとアラートを構成することで、プロジェクト内のすべてのアクティビティがいつでも監査できるように、監査構成の推奨される状態が維持されます。

重大度: 低

カスタム役割の変更のためのログメトリックフィルターとアラートが存在することを確認する

説明: ID とアクセス管理 (IAM) ロールの作成、削除、更新アクティビティの変更に関するメトリックフィルターとアラームを確立することをお勧めします。 Google Cloud IAM には、特定の Google Cloud Platform リソースへのきめ細かいアクセスを許可し、他のリソースへの不要なアクセスを防ぐ定義済みのロールが用意されています。ただし、組織固有のニーズに対応するために、Cloud IAM にはカスタムロールを作成する機能も用意されています。組織ロール管理者ロールまたは IAM ロール管理者ロールを持つプロジェクト所有者と管理者は、カスタムロールを作成できます。ロールの作成、削除、更新アクティビティの監視は、初期の段階で過剰な特権を持つロールを特定するのに役立ちます。

重大度: 低

サービスアカウントのユーザーマネージドまたは外部キーが 90 日以内ごとにローテーションされることを確認する

説明: サービスアカウントキーは、キー ID (Private_key_Id) と秘密キーで構成されます。これは、ユーザーがその特定のサービスアカウントからアクセスできる Google クラウドサービスに対するプログラムによる要求に署名するために使用されます。すべてのサービスアカウントキーを定期的にローテーションすることをお勧めします。サービスアカウントキーをローテーションすると、侵害されたアカウントまたは終了したアカウントに関連付けられているアクセスキーを使用できる期間が短縮されます。サービスアカウントキーをローテーションして、紛失、解読、盗難にあった古いキーでデータにアクセスできないようにする必要があります。各サービスアカウントは、Google Cloud Platform (GCP) によって管理されるキーペアに関連付けられています。これは、GCP 内のサービス間認証に使用されます。 Google ではキーを毎日ローテーションしています。 GCP には、GCP の外部から使用する (たとえば、アプリケーションの既定の資格情報で使用するための) 1 つ以上のユーザー管理キーペア (外部キーペアとも呼ばれます) を作成するオプションが用意されています。新しいキーペアが作成されると、ユーザーは秘密キーをダウンロードする必要があります (Google では保持されません)。

外部キーを使用すると、ユーザーは秘密キーのセキュリティと、キーのローテーションなどの他の管理操作を維持する責任を負います。外部キーは、IAM API、gcloud コマンドラインツール、または Google Cloud Platform Console の [Service Accounts] (サービスアカウント) ページで管理できます。

GCP は、キーのローテーションを容易にするために、サービスアカウントごとに最大 10 個の外部サービスアカウントキーを容易にします。

重大度: 中

GCP のオーバープロビジョニングされた ID には、必要なアクセス許可のみが必要です (プレビュー)

説明: 過剰にプロビジョニングされたアクティブ ID は、使用していない特権にアクセスできる ID です。過剰にプロビジョニングされたアクティブな ID (特に、アクションと責任が非常に定義されている非人間アカウントの場合) は、ユーザー、キー、またはリソースが侵害された場合の爆発半径を増やすことができます。最小限の特権の原則では、リソースが機能するために必要な正確なリソースにのみアクセスできる必要があります。この原則は、攻撃者にさまざまなリソースへのアクセスを許可する侵害された ID のリスクに対処するために開発されました。

次の方法で共有

ID とアクセスのセキュリティに関する推奨事項

Azure ID とアクセスに関する推奨事項

AWS ID とアクセスに関する推奨事項

GCP ID とアクセスに関する推奨事項

関連するコンテンツ

フィードバック

その他のリソース