【登壇レポート】「アカウント統制の健康診断」というタイトルで登壇しました #devio2026

"ID","観点","対象サービス","機能","重要度","設定項目","説明","確認方法"
"GOV-01","統制","AWS Billing and Cost Management","コスト配分タグ","1","コスト配分タグを有効にする","コスト配分タグは、タグを請求レポートやコスト配分の集計軸として使えるようにする設定。ユーザー定義タグは既定で非アクティブのため、タグを付けても請求レポートに出ない。管理アカウントでの有効化が必要で、表示と反映にそれぞれ最大 24 時間かかるため早めに有効化する。あわせて、タグポリシーを活用してタグを標準化し、コスト配分タグに使うタグキーも統一することを推奨する。","管理アカウントで Billing and Cost Management コンソール > コスト配分タグ でステータス列を確認する"
"GOV-02","統制","AWS Control Tower","コントロール","3","Control Tower のリージョン拒否コントロールを設定する","Control Tower のリージョン拒否には、ランディングゾーン全体に一律で効く設定(AWS-GR_REGION_DENY)と、OU 単位で有効にするコントロール(CT.MULTISERVICE.PV.1)がある。どちらも既定で無効で、既定リージョン 17 個はアカウント側で無効化できず常に使える。管理していないリージョンに暗号資産マイニングなどの不正リソースを作られたり、データ所在の要件に違反したりするのを防ぐため、リージョン制限を推奨する。ランディングゾーン全体の設定では柔軟な除外設定ができないが、OU 単位の設定であれば一部の操作を除外できるため、OU 単位での設定を推奨する。例えば、Amazon Bedrock のグローバル推論を利用するために、一部の API の実行を除外アクションとして追加するといった設定ができる。","管理アカウントで Control Tower コンソール > コントロール > Control Catalog で CT.MULTISERVICE.PV.1 を探して開き、「OU は有効です」タブで対象の OU が有効になっていることを確認する"
"GOV-03","統制","AWS Control Tower","コントロール","2","Control Tower のガイダンスが「強く推奨」のコントロールを有効にする","Control Tower で既定で有効になるのは必須コントロールだけで、ガイダンスが「強く推奨」のコントロールは、手動で有効にしない限り適用されない。特に動作が「予防」のコントロールを中心に、有効化を検討することを推奨する。予防のコントロールは SCP による制限として実装されるため、操作そのものを防ぐ直接的な効果が期待できる。","管理アカウントで Control Tower コンソール > コントロール > Control Catalog で、ガイダンス = 強く推奨 のフィルターをかけて検索する"
"GOV-04","統制","AWS Control Tower","ランディングゾーン","2","Control Tower ランディングゾーンを最新バージョンに更新する","ランディングゾーンは自動では更新されない。古いままだと新しい機能が利用できず、最新のコントロール設定も適用されないため、最新バージョンへの更新を推奨する。ただし、一度更新すると以前のバージョンには戻せないため、事前に影響を調査したうえで段階的に更新する。複数の OU がある場合は、リスクの低い OU から順に再登録していくことを推奨する。","管理アカウントで Control Tower コンソール > ランディングゾーン設定 で現在のバージョンと利用可能な更新を確認する"
"GOV-05","統制","AWS Control Tower","ランディングゾーン","1","Control Tower のステータスにエラーが表示されていないことを確認する","Control Tower が管理する OU やポリシーが Control Tower の外で変更され、想定構成とずれた状態になっていないかを確認する。例えば、初期構築後に特定のアカウントを別の OU に移動した際に、リソースが競合して正常に再登録できていない状況をまれに見かける。","管理アカウントで Control Tower コンソール > 組織 でステータスを確認する"
"GOV-06","統制","AWS Control Tower","アカウントの自動登録","1","Control Tower のアカウント自動登録を有効化する","自動登録は、OU 間で移動したアカウントに移動先 OU のコントロールを自動で適用する機能。既定はオフで、移動先の統制が適用されない。","管理アカウントで Control Tower コンソール > ランディングゾーン設定 で自動アカウント登録の設定状態を確認する"
"GOV-07","統制","AWS IAM","ルートアクセス管理","3","メンバーアカウントのルートユーザー認証情報を削除する","ルートアクセス管理は、メンバーアカウントのルートユーザー認証情報を管理アカウントや委任された管理者から削除・管理する機能。既定で無効のため、ルートユーザーのメールアドレスを乗っ取られるとパスワードをリセットされてルートユーザーでサインインされるおそれがある。「ルート認証情報の管理」と「メンバーアカウントでの特権ルートアクション」の両方を有効にし、既存メンバーのルートユーザー認証情報を削除することを推奨する。","管理アカウントで IAM コンソール > ルートアクセス管理 で「リスト」表示に切り替え、すべてのメンバーアカウントの「ルートユーザー認証情報」が「存在しない」であることを確認する"
"GOV-08","統制","AWS Organizations","管理アカウント","3","管理アカウントの用途とアクセスを最小限にする","管理アカウントは組織で最高権限のアカウントであり、SCP などのポリシーが適用されない。侵害や誤操作が組織全体に被害を及ぼすため、用途を管理アカウントでしかできない作業に限定し、アクセス者とルートの認証情報の管理者を定期的に棚卸しする。","(例) 管理アカウントの利用料を確認する、IAM Identity Center で管理アカウントへのアクセス許可を確認する"
"GOV-09","統制","AWS Organizations","ポリシー","3","SCP を設定する","SCP は、メンバーアカウントで使える権限を組織として制限するポリシー。既定では設定が無く、すべての操作が許可されている。EC2 の高額なインスタンスタイプの利用を拒否するなどの設定を検討する。Deny 方式で設計するほうが管理しやすい。なお、管理アカウントには SCP が適用されない点に留意する。","管理アカウントで AWS Organizations コンソール > ポリシー > サービスコントロールポリシー で各ポリシーを開き、「ターゲット」タブで Root や OU にアタッチされていることを確認する"
"GOV-10","統制","AWS Organizations","ポリシー","2","EC2 ポリシーを設定する","EC2 ポリシーは、VPC BPA や AMI・スナップショットの公開ブロック、IMDS の既定値などを組織から一括で設定する宣言型ポリシー。既定では未アタッチで各アカウント・各リージョンの個別設定に任されるため、新しいアカウントやリージョンで設定が漏れる。アカウントステータスレポートで現状を把握してから適用する。","管理アカウントで AWS Organizations コンソール > ポリシー > EC2 ポリシー で各ポリシーを開き、「ターゲット」タブで Root や OU にアタッチされていることを確認する"
"GOV-11","統制","AWS Organizations","ポリシー","2","S3 ポリシーを設定する","S3 ポリシーは、アカウントレベルの S3 Block Public Access を組織として一括で設定する宣言型ポリシー。既定では設定が無く、アカウントの管理者が Block Public Access を解除して公開バケットを作れる。Root や OU で Block Public Access を一括で有効にすることを検討する。なお、ポリシーで設定するとアカウント側では変更できなくなる点に留意する。","管理アカウントで AWS Organizations コンソール > ポリシー > S3 ポリシー で各ポリシーを開き、「ターゲット」タブで Root や OU にアタッチされていること、「コンテンツ」タブで public_access_block_configuration が all であることを確認する"
"GOV-12","統制","AWS Organizations","ポリシー","2","バックアップポリシーを設定する","バックアップポリシーは、AWS Backup のバックアッププランを組織から各アカウントに配布するポリシー。既定では設定が無く、バックアップの有無が各アカウント任せになるため、アカウントごとにバックアップが漏れ、復旧手段も統一されない。重要データを持つ OU に配布することを検討する。関連する設定として、Control Tower の設定で AWS Backup のオプトインも検討できる。","管理アカウントで AWS Organizations コンソール > ポリシー > バックアップポリシー で、対象のバックアップポリシーが存在することを確認する"
"GOV-13","統制","AWS Organizations","ポリシー","2","GuardDuty ポリシーを設定する","GuardDuty ポリシーは、Amazon GuardDuty と各保護プラン(S3 Protection・Runtime Monitoring など)を Root・OU・アカウント単位で組織から一括で有効化するポリシー。既定では設定が無く、リージョンごとの自動有効化設定やアカウントごとの手作業に任されるため、新しいアカウントやリージョンで有効化が漏れる。OU 単位で、対象とするリージョンを指定して設定することを検討する。","管理アカウントで AWS Organizations コンソール > ポリシー > GuardDuty ポリシー で、対象の GuardDuty ポリシーが存在することを確認する"
"GOV-14","統制","AWS Organizations","ポリシー","2","Inspector ポリシーを設定する","Inspector ポリシーは、Amazon Inspector とスキャン種別(EC2・ECR・Lambda・コードスキャンなど)を Root・OU・アカウント単位で組織から一括で有効化するポリシー。既定では設定が無く、アカウントごとの有効化に任されるため、新しいアカウントで脆弱性スキャンが漏れる。","管理アカウントで AWS Organizations コンソール > ポリシー > Inspector ポリシー で、対象の Inspector ポリシーが存在することを確認する"
"GOV-15","統制","AWS Organizations","ポリシー","1","RCP を設定する","RCP は、組織内のリソースへのアクセスを組織として制限するポリシー。SCP が組織内の ID の操作を制限するのに対し、RCP は組織外の ID も含めてリソースへのアクセスを制限する。既定では設定が無く、すべてのアクセスが許可されている。組織外の ID から S3 や KMS へのアクセスを拒否するなどの設定を検討する。なお、管理アカウントのリソースには RCP が適用されない点に留意する。","管理アカウントで AWS Organizations コンソール > ポリシー > リソースコントロールポリシー で各ポリシーを開き、「ターゲット」タブで Root や OU にアタッチされていることを確認する"
"GOV-16","統制","AWS Organizations","ポリシー","1","タグポリシーを設定する","タグポリシーは、タグキーの表記や許容値を組織として標準化するポリシー。既定では設定が無く、タグの表記ゆれやタグの無いリソースがあると、コスト配分・ABAC・自動化が機能しない。レポートで準拠状況を確認してから強制することを検討する。なお、タグポリシーでタグを付けること自体は強制できない。また、enforced_for を指定しない限り、非準拠のタグ付けはブロックされない点に留意する。","管理アカウントで AWS Organizations コンソール > ポリシー > タグポリシー で、対象のタグポリシーが存在することを確認する"
"GOV-17","統制","AWS Organizations","ポリシー","1","AI サービスのオプトアウトポリシーを設定する","AI サービスのオプトアウトポリシーは、AWS の AI サービスが顧客コンテンツをサービス改善に使うことを組織として拒否するポリシー。既定では設定が無くオプトイン扱いのため、顧客コンテンツがサービス改善に使われ、利用リージョンの外に保存されることもある。データ所在や契約の要件に違反しないよう、Root でオプトアウトすることを検討する。","管理アカウントで AWS Organizations コンソール > ポリシー > AI サービスのオプトアウトポリシー で、対象の AI サービスのオプトアウトポリシーが存在することを確認する"
"SEC-01","セキュリティ","AWS CloudTrail","証跡","3","CloudTrail の組織の証跡を作成する","既定では証跡がなく、イベント履歴にリージョンごとの管理イベントが 90 日分残るだけである。90 日を過ぎた調査や組織横断の分析ができないため、組織の証跡を作り、ログアーカイブアカウントの S3 に集約する。Control Tower を利用している場合は、ランディングゾーン設定で AWS CloudTrail のログ記録をオプトインすることを推奨する。オプトインすると、組織の証跡とログアーカイブアカウントへの集約が自動で構成される。なお、組織の証跡を有効にした後、アカウントごとに作成していた証跡が残っている場合は、削除を検討する。管理イベントを記録する証跡は 1 つ目のみ無料で、2 つ目以降の証跡では利用料が発生するためである。","管理アカウント(または委任管理者)で CloudTrail コンソール > 証跡 で、組織の証跡 が はい となっている証跡があることを確認する"
"SEC-02","セキュリティ","AWS Config","設定","3","AWS Config を有効にする","AWS Config は、リソースの構成と変更履歴を記録する機能。既定では何も記録されず、リージョンごとに有効にする必要がある。構成変更の履歴が残らないうえ、Security Hub CSPM のほとんどのコントロールも評価できなくなるため、有効にする。Control Tower を利用している場合は、ランディングゾーン設定で AWS Config をオプトインして有効化することを推奨する。","各アカウントで Config コンソール > 設定 で、レコーダーが 記録はオン となっていることを確認する"
"SEC-03","セキュリティ","AWS Control Tower","Account Factory","1","Account Factory で新しいアカウントに VPC を作成しない設定にする","Account Factory は、Control Tower で新しいアカウントを作成する機能。既定のネットワーク設定では、アカウントを作成するたびに、利用できるすべてのリージョンに VPC が作られる。CIDR も既定で全アカウント共通となる。使わない VPC が全リージョンに残ると、管理の目が届かないネットワークが増えるうえ、後からネットワークを接続するときに CIDR が重複する。VPC はワークロードの要件に合わせて別途設計して作成することとし、Account Factory では VPC を作成しない設定にすることを推奨する。なお、この設定は以降に作成するアカウントにだけ適用され、作成済みのアカウントの VPC は残る点に留意する。","管理アカウントで Control Tower コンソール > Account Factory > ネットワーク構成 で、インターネットアクセス可能なサブネット が 不許可 かつ プライベートサブネットの最大数 が 0 であること、または VPC 作成のリージョン が 1 つも選択されていないことを確認する"
"SEC-04","セキュリティ","Amazon Detective","グラフ","1","Amazon Detective を有効にする","Amazon Detective は、ログをもとにインシデントの原因分析を支援する調査基盤。既定では無効で、検知後の原因分析に時間がかかるため、GuardDuty と同じ委任管理者で有効にする。なお、分析できるのは有効にした後に収集したデータのみで、有効にする前の期間はさかのぼって分析できない。","Detective コンソールを開き、概要 ページが表示されることを確認する"
"SEC-05","セキュリティ","Amazon EBS","デフォルト暗号化","2","EBS のデフォルト暗号化を有効にする","EBS のデフォルト暗号化は既定で無効(リージョンごとの設定)。","各アカウントで EC2 コンソール > ダッシュボード > アカウントの属性 > データ保護とセキュリティ > EBS 暗号化 を確認する"
"SEC-06","セキュリティ","AWS IAM","ルートユーザー","3","ルートユーザーに MFA を設定する","ルートユーザーの MFA デバイスの登録は、利用者の操作に委ねられている。古いアカウントでは、未登録のまま残っていることがある。ルートが乗っ取られると、アカウント全体を掌握される。ルートユーザーに MFA を登録する。メンバーアカウントは、ルートアクセス管理でルートユーザーの認証情報そのものを削除することを推奨する。","管理アカウントで IAM コンソール > 認証情報レポート > 認証情報レポートをダウンロード → <root_account> 行の mfa_active が true であることを確認する"
"SEC-07","セキュリティ","AWS IAM","IAM ユーザー","3","IAM ユーザーと長期アクセスキーを廃止する","IAM ユーザーは既定では存在しないが、過去に作られたユーザーやキーは放置されやすい。アクセスキーの漏えいは侵入原因の上位であるため、人は Identity Center、ワークロードは IAM ロールに移し、長期認証情報をなくす。既存でアクセスキーを使った運用をしている場合は、OIDC での接続など別の代替手段がないかを確認し、なるべくアクセスキーを利用しない構成とする。","各アカウントで IAM コンソール > ユーザー で IAM ユーザーの有無を確認 → 認証情報レポート > 認証情報レポートをダウンロード でアクセスキーの最終ローテーション日・最終使用日を確認する"
"SEC-08","セキュリティ","IAM Access Analyzer","外部アクセスアナライザー","2","外部アクセスアナライザーを作成する","外部アクセスアナライザーは、S3、KMS、IAM ロール、スナップショットなどが外部に共有されていないかを検出する機能。既定では未作成で、分析対象は作成したリージョンのリソースに限られるため、全リージョンに作成する。","IAM コンソール > Access Analyzer > アナライザー設定 で、検出結果のタイプが 外部アクセス のアナライザーがあることを確認する。委任された管理者を設定している場合は、そのアカウントで確認する"
"SEC-09","セキュリティ","AWS IAM Identity Center","組織インスタンス","2","IAM Identity Center の組織インスタンスを有効にする","IAM Identity Center は、組織内の複数アカウントへの人のアクセスを許可セットで一元管理する機能。既定では未導入で、使わないと IAM ユーザーが乱立し、長期認証情報や退職者のアカウントが残るため導入する。","管理アカウントで IAM Identity Center コンソール > 設定 > 詳細 で、インスタンスタイプが 組織インスタンス となっていることを確認する"
"SEC-10","セキュリティ","AWS IAM Identity Center","ID ソース","2","外部 IdP 側で MFA を強制する","外部 IdP を使う場合、Identity Center 側には MFA の設定欄が出ず、MFA の要否は IdP 側の設定に委ねられる。IdP 側で MFA を強制していないとパスワードだけで AWS にサインインできてしまうため、IdP 側で強制する。","-"
"SEC-11","セキュリティ","AWS IAM Identity Center","許可セット","2","IAM Identity Center のセッション時間を短く設定する","セッション時間は、一度サインインした後に再認証なしで使える時間。端末の盗難やトークンの漏えいが起きたとき、長いほど悪用できる時間が延びるため、業務に必要な範囲で短くする。","Identity Center の管理アカウント(または委任管理者)で IAM Identity Center コンソール > 設定 > 認証 タブ > セッション期間 でユーザーインタラクティブセッションを確認する → 許可セット > 各許可セット の詳細でセッション期間を確認する"
"SEC-12","セキュリティ","AWS Organizations","管理アカウント","2","管理アカウントを含め、有効なすべてのリージョンでセキュリティサービスを有効にする","GuardDuty や Security Hub CSPM などのセキュリティサービスは、リージョンごとに有効にする必要がある。SCP でリージョンを制限している場合、中央設定や Organizations 統合では、許可したリージョンを指定して有効化することが多い。ただし、SCP は管理アカウントには適用されないため、管理アカウントでは許可リージョン以外のリージョンも使えるにもかかわらず、セキュリティサービスが有効になっていないリージョンが残る場合がある。そのため、セキュリティサービスを有効化する設計では、管理アカウントとそれ以外のメンバーアカウントを分けて設計し、管理アカウントで有効化の漏れがないように設定することを推奨する。","-"
"SEC-13","セキュリティ","AWS Security Hub CSPM","セキュリティ標準","2","Security Hub CSPM を有効にする","Security Hub CSPM は、設定ミスをセキュリティ標準に照らして継続的に評価する機能(旧称 AWS Security Hub)。既定では無効である。まずは FSBP から有効にする。中央設定で一元管理することが望ましい。","委任された管理者のホームリージョンで Security Hub CSPM コンソール > 設定 > 設定 を開き、中央設定 にポリシーがあることを確認する。組織 タブで、各 OU のポリシーのステータスが 適用済み となっていることを確認する"
"SEC-14","セキュリティ","AWS Security Hub CSPM","コントロール","1","Security Hub CSPM の統合されたコントロールの検出結果をオンにする","統合されたコントロールの検出結果は、同じコントロールが複数のセキュリティ標準に含まれる場合でも、チェック 1 件につき検出結果を 1 件だけ生成する設定である。オフのままだと標準ごとに検出結果が作られるため、複数の標準を使っていると同じ設定ミスのアラートが標準の数だけ分かれて届く。コンソールから Security Hub CSPM を有効にした場合は原則として既定でオンになるが、有効化の方法によっては既定でオンにならない。特に中央設定で有効にした場合は既定でオフのままとなるため、オンにすることを推奨する。なお、オンにすると検出結果の一部の項目の内容が変わるため、通知の仕組みに影響がないかを確認したうえで設定を変更する。","委任された管理者で Security Hub CSPM コンソール > 設定 > 一般 > コントロール で、統合されたコントロールの検出結果 が オン であることを確認する"
"SEC-15","セキュリティ","AWS Systems Manager","ドキュメント","1","SSM ドキュメントのパブリック共有をブロックする","SSM ドキュメントは、Systems Manager で実行する手順やスクリプトの定義。パブリック共有のブロックは既定で無効で、ドキュメントをすべての AWS アカウントに公開できる。スクリプト内の認証情報や内部情報が公開されないよう、パブリック共有をブロックする。ブロックを有効にしても公開済みのドキュメントの共有状態は変わらないため、公開済みのドキュメントがないかもあわせて確認する。","各アカウントで Systems Manager コンソール > Documents > Preferences の Block public sharing (with all AWS accounts) で、Block public sharing setting が On となっていることを確認する"
"OPS-01","運用","AWS Account Management","代替連絡先","2","全アカウントに代替連絡先を登録する","代替連絡先は、AWS からの通知をルートユーザー以外の宛先にも届ける設定である。既定では未登録で、連絡はルートユーザーのメールアドレスにしか届かない。不正利用やセキュリティ通知、請求の連絡が担当者に届かず初動が遅れるのを防ぐため、チームのメーリングリストを登録する。","管理アカウントで Organizations コンソール > AWS アカウント > 対象アカウント > 連絡先情報 タブ > 代替連絡先 で、請求に関する連絡先・オペレーションに関する連絡先・セキュリティに関する連絡先 が なし ではなく登録されていることを確認する"
"OPS-02","運用","AWS Backup","コピー","2","バックアップを別アカウント・別リージョンにコピーする","既定ではクロスアカウントバックアップは無効で、管理アカウントだけが有効にできる。同じアカウント・リージョンにしかバックアップが無いと、アカウントの侵害やリージョン障害でバックアップも一緒に失う。中央のバックアップ用アカウントや別リージョンにコピーして備える。Control Tower を利用している場合は、ランディングゾーン設定で AWS Backup のオプトインも検討する。","各アカウントで AWS Backup コンソール > バックアッププラン > 対象プラン で、バックアップルールのコピー先を確認する"
"OPS-03","運用","AWS Budgets","予算","2","AWS Budgets で予算とアラートを設定する","既定では予算は作られていない。予算が無いと、予算超過や想定外の請求に月末の請求書まで気付かないため、実績と予測でアラートを出す。","管理アカウントで 請求とコスト管理 コンソール > 予算 で対象の予算を確認する"
"OPS-04","運用","Amazon CloudWatch Logs","ロググループの保持期間","2","ロググループの保持期間を設定する","既定の保持期間は無期限で、Lambda などが自動で作るロググループも同じである。放置するとストレージ費用が増え続ける。既にデータがあるグループに短い期間を設定すると古いログがすぐ消えるため、注意して設定する。","各アカウントで CloudWatch コンソール > ログ > ログ管理 > ロググループ タブ で、保持 列が 失効しない のロググループがないことを確認する"
"OPS-05","運用","AWS Control Tower","通知","1","Control Tower の既定の通知を使わず、Config ルールの非準拠だけを通知する","Control Tower は、各リージョンの aws-controltower-SecurityNotifications トピックで受けた AWS Config の通知を、監査アカウントの aws-controltower-AggregateSecurityNotifications トピックに集約し、既定で監査アカウントのメールアドレスに送る。この通知は準拠・非準拠を問わず AWS Config の変更のたびに届き、JSON 形式のままのため、量が多く読み取りにくい。セキュリティイベントの検出は、原則として Security Hub CSPM の検出結果を活用するのがシンプルである。Config ルールの評価結果を通知したい場合は、既定の通知は使わず、Lambda 関数などで非準拠となった評価結果だけを抽出・整形して通知する仕組みを組み込むことを推奨する。","監査アカウントで Amazon SNS コンソール > トピック > aws-controltower-AggregateSecurityNotifications > サブスクリプション タブ で、監査アカウントのメールアドレスへの既定のサブスクリプションが残っていないことを確認する"
"OPS-06","運用","AWS Cost Anomaly Detection","コストモニター","1","Cost Anomaly Detection で組織全体のコストモニターを作成する","Cost Anomaly Detection は、コストの異常な増加を検知して通知するサービスである。","管理アカウントで 請求とコスト管理 コンソール > コスト異常検出 > コストモニター タブでモニターを確認 → アラートサブスクリプション タブで、モニターがアタッチされたサブスクリプションがあることを確認する"
"OPS-07","運用","Cost Optimization Hub","組織オプトイン","2","Cost Optimization Hub と AWS Compute Optimizer に組織でオプトインする","Cost Optimization Hub と AWS Compute Optimizer は、リソースのサイズ見直しや購入オプションの推奨を出すサービスである。既定ではオプトインしておらず推奨が出ないため、削減の機会を逃す。組織でオプトインすると、後から加わるアカウントも自動で対象になる。","管理アカウントで 請求とコスト管理 コンソール > コスト管理の設定 > コスト最適化ハブ タブで、コスト最適化ハブを有効にする と すべてのメンバーアカウントでコスト最適化ハブを有効化 がオンであることを確認 → Compute Optimizer コンソール > 設定 > アカウント管理 の アカウント別の組織のオプトイン で、すべてのアカウントの オプトインステータス が アクティブ であることを確認する"
"OPS-08","運用","AWS Health","組織ビュー","1","AWS Health の組織ビューを有効にする","組織ビューは、全アカウントの Health イベント(メンテナンスや廃止予定)を 1 か所で見る機能である。既定では無効で、有効化前のイベントは見られない。アカウントごとに見に行くと見落としが出るため、早めに有効にする。","管理アカウントで AWS Health Dashboard > 組織の状態 > 設定 で、AWS Health の組織ビューを有効にする が 成功 となっていることを確認する"
"OPS-09","運用","Amazon S3","ライフサイクル設定","2","ログ用などの S3 バケットにライフサイクルルールを設定する","既定ではライフサイクルが設定されておらず、オブジェクトは S3 Standard のまま永続保存される。ログやアーカイブは量が増え続けるため、放置するとストレージ費用が増え続ける。Glacier などへの移行や、期限切れ・非現行バージョンの削除を設定する。","各アカウントで Amazon S3 コンソール > 汎用バケット > ログ用などの対象バケット > 管理 タブ > ライフサイクルルール で、移行・期限切れ削除・非現行バージョン削除のルールがあるか確認する"
"OPS-10","運用","Amazon SNS","通知基盤","3","各種検出結果を通知する","既存のサービスには、検出結果をまとめて通知する仕組みがない。そのため、通知の仕組みはカスタムで作る必要がある。Security Hub CSPM に取り込まれた検出結果を中心に、EventBridge と Step Functions を経由して文章を整形したうえで、通知基盤から通知することができる。例えば、GuardDuty、Security Hub CSPM、Inspector、AWS Health などのイベント情報を集約して通知する。","-"

添付の CSV は AWS アカウント統制の点検項目(42 項目)です。
各項目の「確認方法」を参考にして、設定済みであるかを確認してください。
AWS 環境を操作する場合は、読み取り専用の操作のみとし、設定変更は行わないでください。
判定できない項目は、観点ごとにまとめて私に質問してください。
設定済みの項目の「重要度」を合計し、満点 80 点に対する得点率で
A(90% 以上)/ B(70〜89%)/ C(50〜69%)/ D(50% 未満)を判定してください。
最後に、未設定の項目を重要度の高い順に一覧にしてください。