初めてAWSを使うときのセキュリティ覚書〜管理者編〜

初めてAWSを使っていくときに読んでおきたいセキュリティの覚書、管理者編です。これからAWSの管理者となる人は是非読んでください。あるいは管理者を任せる方が活用してください。
#AWS
#セキュリティ
臼田佳祐
2025.01.08
こんにちは、臼田です。
みなさん、AWSのセキュリティ気にしてますか？(挨拶
今回はこれからAWSを使う組織や使い始めた組織向けに、AWSセキュリティで絶対に覚えておく必要があることを解説します。
この記事を読んでいただければ、自信を持って安全にAWSを利用し始められます！
なお、初めてAWSを使う利用者に向けた記事として初めてAWSを使うときのセキュリティ覚書〜利用者編〜 | コラム | クラウドソリューション｜サービス｜法人のお客さま｜NTT東日本を先に掲載しています。本記事はこの続編で管理者としての内容を綴っていきます。まだ読んでいない方は先にそちらをご覧ください。
目次
前置き〜AWSの管理は大変？〜
組織における情報セキュリティの基礎
組織の情報セキュリティとAWS
組織のAWS管理でやること
利用者にやってもらうこと
AWS管理のネクストステップ
 1.前置き〜AWSの管理は大変？〜ここを読んでいる、組織の管理者となるみなさんは、すでに利用者編を読んできているはずです。どのような印象を持ちましたか？
「管理者のハードル高くない？」と感じている方、そのとおりです。組織の情報セキュリティを管理していくことは簡単ではありません。一口にセキュリティといっても幅広い対応が必要になります。だからこそ組織全体の情報セキュリティを管理することに意味があり価値があります。
組織におけるAWS管理に必要なことはこの記事でまとめます。組織全体の課題を解決していくための取り組みであるため、利用者編以上に簡単にできないこともありますが、1つずつ取り組んでいきましょう。
 1-1.本記事の対象読者この記事は主に以下のような方を対象としています。
これからAWSを触り始める組織の管理者
プロダクトなど事業部門の管理者
AWSの全体管理を行う方
これからプロダクト単位や組織全体のAWS利用について責任を持つ管理者として、基本的な技術のレベル感は高めで書いていきますが、初めて全体の管理を行う方をイメージして丁寧に解説していきます。気になる用語が出てきた場合には別途調べてください。
 2.組織における情報セキュリティの基礎組織全体でAWSを適切に利用していくために、そもそも組織におけるAWSに限らない全般的な情報セキュリティを理解していく必要があります。まずはここから始めましょう。
 2-1.組織セキュリティの目的利用者編からの繰り返しですが、セキュリティはビジネスのために行います。あくまでビジネスを守るためにセキュリティ対策を行います。(多くの営利企業の場合)
セキュリティ対策を行っていくには費用がかかりますし、常に費用と効果のバランスを見ながら、ビジネス規模にあったセキュリティ対策を行っていきます。
組織としてセキュリティを全体に適用していくことは、組織全体にガードレールとしてセキュリティを導入できたり、全体で行うことでコストを最適化したり、利用者の責任範囲を減らしよりビジネスを推進しやすくするなど様々な目的があります。
ビジネスのブロッカーにならないように、管理者と利用者が寄り添って、原理的に正しくかつ利便性に優れた組織セキュリティを目指していく必要があります。
 2-2.組織におけるセキュリティの責任範囲セキュリティの責任は誰が持つのでしょうか？組織全体における情報セキュリティの責任者は経営者です。経営者は最終的に組織全体の意思決定の責任を持ちます。必要に応じ、CIOやCISOなどにこの実行責任を委譲します。しかし最終的な説明責任は経営者が持ち、ステークホルダーに対してこれを果たす義務があります。
説明責任(Accountability)と実行責任(Responsibility)は、組織における情報セキュリティの責任範囲を考えるうえで重要な、責任の区分についての考え方です。この概念は書籍AWSではじめるクラウドセキュリティでも詳しく説明されていますので、合わせて参照してください。
組織内の全体的なセキュリティについては管理者側でそれを設計し、仕組みを整備できる部分は説明責任も実行責任も負っていきます。組織に必要なID基盤やエンドポイント管理の仕組みなど幅広い情報システムを整備し、マニュアルなどを整備していきます。
一方で利用者が利用する範囲に対しては、実行責任をどんどん渡していきます。すべての人にたくさんの実行責任を渡していくことはできませんので、その人の役割や役職に応じてコントロールします。例えばAWSでいうと、事業部門の責任者に対して該当AWSアカウントの管理者に命じ、必要な対策をしてもらうように権限と責任を委譲していきます。該当AWSアカウント内での詳細なアクセス制御(誰がどの権限で何を利用できるかというコントロール)は、全体の管理者が詳細に把握しきれないため、事業部門の責任者に委譲する場合がある代表的な項目です。その代わり、その判断基準や禁止事項などを組織の管理者が定義しガイドラインに記載するなど、分担する場合がほとんどでしょう。つまり、一般的な組織におけるセキュリティは固定的で明確な責任分担はあまりなく、組織の状況に応じて柔軟に変わっていくものです。
組織のセキュリティを管理していく場合、この責任範囲をなるべくわかりやすくしていく必要があります。規定などのルールやガイドラインなどの参考情報を作成して見える形にしてから管理者と利用者が前向きに議論できる状況にしていくことが好ましいでしょう。
 2-3.組織のセキュリティ文化作り責任範囲にもあるように、組織におけるセキュリティでは組織の文化が大きく影響します。組織内で管理者と利用者が険悪でお互いの責任範囲を守らず押し付け合い結果正しいセキュリティ対策が実行されないことは、大きなビジネスの損失に繋がります。良い文化を作るための確実な手段や決められた手法はありませんが、以下の考え方は役に立ちます。
原理的に正しい仕組み作りを目指す
後付けのセキュリティや利用者の負担を強いるセキュリティは効果が薄い
セキュリティはシンプルである必要がある
原理的に正しければシンプルにしやすい
迷ったらシンプルにする

原理的に正しいセキュリティを目指すと無駄なコストを減らせる

ただし原理主義者になってはいけない

経営層からトップダウンでITシステムと情報セキュリティに対するコミットメントをする
経営者は説明責任を果たす必要がある
行っていることのすべてを理解する必要はないが、経営上の判断のために必要なことは把握する
組織の情報セキュリティのポリシーを理解し・承認し・その実行が適切に行われているかを把握する
丸投げではなく具体的にコミットする
組織の編成や資源の分配を行う
実行責任を果たすCISOなどの人選を行い、実行責任を持つものに適切な権限を付与する


すべての人がセキュリティに責任を持つ

責任のない人はいない
役割に応じた範囲の責任を委譲する
責任の範囲はなるべく明確にしていく

方針と文化は繰り返し明言し体現する
入社時の教育だけで理解できることは少ない
トップダウンで組織の方針や文化を明言し、実際に体現していく必要がある

ボトムアップによる生産的な取り組みを推奨する
適切な責任と適切な権限を持つ人が、適切な目的の理解と共にあることで生産的な仕事ができる
ボトムアップのアプローチを過度にブロックせず称賛する

リスクベースでビジネスとセキュリティのバランスを取る
完璧なセキュリティは存在しないし、リスクのないビジネスは存在しない
このバランスを取ることが経営判断
セキュリティリスクが高くこれにかけるコストも高く、ビジネスの利益が見込めないならそれはビジネスリスクが高く採算がれないため止めるべき

共通の組織目標を意識した対話と調整を行う
各チームの目的が相反すると衝突が起き生産的な仕事ができなくなる
より全体の共通した組織目標を意識したチームの目的づくりを行う
すべての人が生産的な対話と調整ができるよう組織を作る

継続的に多段階の教育を行う
役割に応じて様々なレベルのセキュリティに関する教育を行う
様々な背景の人が共通の理解と認識で役割を果たせるようにする
AWSアカウントの利用者とAWSアカウントの管理者はそれぞれ違うレベルの教育が必要

社会やビジネスに合わせた変革を恐れない
極端に保守的になった組織はビジネスを成功に導けない
社会やビジネスの状況に合わせて組織も変わる必要がある
変革には合理的な経営層のコミットメントと支援によって全員が生産的に参加できる土壌が必要


ここに上げたものだけが正解でもありません。組織の状況や環境にあった文化作りを行い、組織全体の情報セキュリティが一部の人に依存せず、ポジティブに保たれる状態を目指しましょう。
 3.組織の情報セキュリティとAWS組織の情報セキュリティはAWSだけに適用されるものではありません。組織の情報セキュリティで取り組むべき大きな課題を理解し、その中でAWSがどのように関わるかを把握しましょう。
 3-1.組織の情報セキュリティで取り組むこと情報システムはビジネスの様々な領域で欠かせない存在になっています。組織として整備する情報システムには以下のような情報セキュリティの取り組みが必要になります。
情報セキュリティ業務の定義運用
セキュリティポリシーを整備し、これを具体的に実施できるようにしていく
例えばISO/IEC 27000シリーズなどを参照しISMSなどを整備する

ID管理とアクセス制御
情報システムにおいてIDは必須の要素
個人に対してシステムごとにたくさんのIDが存在すると管理が複雑になり事故が発生する
組織全体で統合されたID管理の仕組みを整備し、アクセス制御を正しく行えるようにする
シングルサインオン(SSO)を実現する
ただし権限の付与がすべて中央に任されるとビジネスの速度が損なわれるため、権限の管理は事業部門などに適切に委譲できる必要がある
大元のIDは1箇所に集約しつつ、必要に応じて別のID基盤と連携する

データ管理

データの分類を定義しラベリングを行う
分類に従った管理方法とセキュリティのレベルを定義する
アクセス制御・暗号化・可用性・バックアップなどの戦略を立てる

基幹システムの整備と管理
組織全体で必要になる情報システムを用意し管理する
全て自分たちでスクラッチで作る必要は無く、SaaSやクラウドなども幅広く扱う

エンドポイント管理
従業員の端末など業務を行うためのエンドポイントを管理する
安全で快適に基幹システム利用や事業を行えるようにする

事業における情報システムの制御
社内向け・社外向けに構築・利用される情報システムを把握し制御する
事業部門の事業活動を推進しつつ、適切に分担管理する
インフラやプラットフォームの調達管理は全体で行うなど事業部門がビジネスに集中できる環境を整える
ガイドラインやテンプレートを整備し組織の求めるセキュリティレベルを確保しやすくする


統合したセキュリティ管理と監査

全体的なセキュリティの情報を集約し組織全体の状況を把握できるようにする
脆弱性管理など全体で統合した方が良い管理を行う
SOC/CSIRTなどのセキュリティ運用体制を整備する
内部・外部の監査を行い適切な環境を保つ

情報セキュリティ教育
ISMSなど組織の方針にあった全体教育
扱う情報に応じたコンプライアンス教育
取り扱うIT技術の教育
経営者や管理者など責任者に対する教育
これらの教育を実施する体制の整備
資格取得などの推奨

BCDR

事業継続計画の策定
事業継続計画に基づき各部門が適切に取り組めるように全体の整備
実施状況の確認

新技術・新サービスへの対応
新しい技術やサービスを常に受け入れてビジネスを推進できるように取り組む
セキュリティポリシーに照らし合わせて新技術を評価し、新しいガイドラインなどを整備する
リスクアセスメントを行い利用を判断する


これはあくまで一例です。全体最適を図るために必要な取り組みを行いましょう。
 3-2.AWSの関係する取り組み上記に挙げた取り組みのうち、AWSに関係するものを考えていきます。
情報セキュリティ業務の定義運用
AWSも一部関係します
AWSにも適用できるようにポリシーと運用を整備する必要があります
セキュリティポリシーや実施方法は状況に合わせて柔軟に対応する必要があります

ID管理とアクセス制御
AWSも一部関係しますが、一般的に組織全体のIDの管理は別で行われます
例えばMicrosoft Entra IDなど、従業員のIDを集約管理し様々な情報システムと連携できる手段がより適切です
AWSは特にAWS内におけるID管理とアクセス制御を行います
SSOを実現するため、必要に応じMicrosoft Entra IDやOktaなどのIdPと連携します
AWSアカウントの管理者などにアクセス制御を適切に権限委譲します

データ管理
AWSも特に関係します
AWS上では様々なデータを扱います
組織の定義に合わせてAWS上でもデータを分類しラベリングしていきます
各データがどこにあるかを明確化し、アクセス制御を適用します

基幹システムの整備と管理
AWSも基幹システムの一部となる場合があります
エンドポイント管理
AWSはあまり関係ありません
AWSを利用してエンドポイント管理のためのシステムを構築運用することはあります

事業における情報システムの制御
特にAWSが活用される取り組みです
社内向け・社外向けに構築・利用される情報システムで活用します
AWSをインフラ・プラットフォームとして整備します
AWSを利用するためのガイドラインやテンプレートを整備します

統合したセキュリティ管理と監査
AWSもこの影響を受けます
必要に応じAWSの機能を利用してより快適なセキュリティの管理を実行します
AWSが責任を持つ領域は第三者機関により監査を受けておりオフロードできます

情報セキュリティ教育
AWSも教育対象の環境と技術の一部です
AWSが提供するトレーニングコンテンツを活用できます
AWSの利用者とAWSの管理者それぞれ教育が必要です

BCDR
AWSも特に対象となる基盤です
事業継続計画の目的に沿ったサービス選定をし対策を実施します

新技術・新サービスへの対応
AWSもよく活用されます
AWSが新しい技術やサービスをどんどん提供するため、すばやくトレンドの技術を検証することが可能です


AWSは多数のサービスと機能を提供しており、柔軟性の高さから組織の様々な情報システムに活用されます。その結果関係する領域も幅広くなります。一方で情報システムの中核になるID管理の大元はAWS外であったり、エンドポイント管理においてはAWSとあまり関係がないなど、AWSだけで組織の情報セキュリティは満たせないことも留意してください。AWSにおける情報セキュリティはAWS以外の組織セキュリティに関する取り組みの影響を強く受けます。
 4.組織のAWS管理でやること組織の情報セキュリティにおいて特にAWSを利用するためにやることを列挙していきます。特に組織で初めてAWSを利用していく場合や、初めて組織で情報システムを整備していく場合にフォーカスします。
以下項目について深堀りします。
AWSアカウント分割の戦略
AWS IAM
ガバナンス機能
データ管理
 4-1.AWSアカウント分割の戦略AWSではAWSアカウントが一番大きな環境の分割単位になります。複数のシステムを運用する場合や、1つのプロダクトでも開発フローの中で開発・検証・本番のように環境分けする場合にはそれぞれAWSアカウントを分割していくことがベストプラクティスです。
AWSアカウントは他のAWSアカウントとデフォルトで独立しており、強力な論理的境界線として機能します。作成したリソースは基本的にAWSアカウント内に閉じており、外部からのアクセスには明示的な許可設定が必要になるため、不要なアクセスを防止できます。万が一AWSアカウントが乗っ取られた場合でも、影響範囲(Blast Radius)はそのAWSアカウントの中に留めることが可能であるため、特に開発環境と本番環境は分割が必須です。開発環境が侵害されて、本番データも漏洩しました、という事態はあってはなりません。何よりそのような構成は顧客に説明がつかないでしょう。
AWSアカウントを細かく分割していくことがベストプラクティスな一方で、これを行っていくと大量のAWSアカウントの管理が煩雑になります。そこで利用する機能がAWS Organizationsです。AWS Organizationsは1つの組織としてAWSアカウントをまとめて管理するサービスです。AWS Organizationsを利用することで階層的にAWSアカウントを管理し、必要に応じてアカウント間の連携としてSSOやデータの集約など様々な機能が利用できます。AWSマルチアカウント管理の戦略としてAWS Organizationsの利用を行う場合、マルチアカウント管理のベストプラクティス - AWS Organizationsも参照してください。
しかし、AWS Organizationsの利用が契約上、あるいは運用上難しい場合もあります。可能であれば採用する程度の検討で問題ありません。AWS Organizationsを利用できない場合でも近しい管理は可能です。この後の内容でも要所で触れます。まずはAWSアカウントを環境ごと細かく分割するところから始めましょう。
 4-2.AWS IAMAWSのセキュリティはIAMに始まりIAMに終わると言っても過言ではありません。AWSにおけるIAMの重要性と構成要素、基本的なアクセス制御については利用者編で解説していますのでそちらを参照してください。
もし組織のID基盤が整備されているのであれば、AWSもSSOでアクセスできるように、Microsoft Entra IDやOktaなどのIdPと連携することを第一候補としましょう。AWS上でSSOを行うためのサービスであるAWS IAM Identity CenterとIdPを連携することで、他のアプリケーションと同じようにSSOすることが可能です。
組織のID基盤が整備されていなかったり、ID基盤とAWSなどのプラットフォームを連携させることが用意ではない場合、AWSの世界に閉じたID集約の手法として、1つのAWSアカウントにIAMユーザーを集約するJumpアカウント方式を採用しましょう。
AWSアカウントとIAMの管理方法についてはマルチアカウントな AWS環境のマネジメントコンソールへのアクセス方法をまとめてみた | DevelopersIOも参考になりますので合わせてご確認ください。AWSアカウントは前述の通り細かく分割していくことがベストプラクティスですから、これに合わせていずれかの管理方法を採用しましょう。間違ってもすべてのAWSアカウントでそれぞれIAMユーザーを作成することが無いようにしましょう。現代においてこれはメリットが無くリスクしかありません。
今回はJumpアカウント方式について掘り下げていきます。Jumpアカウント方式は以下のように、たくさんあるAWSアカウントのうちIAMユーザーを作成するAWSアカウントを1つに絞り、そこから実際に利用するAWSアカウントにスイッチロールしてアクセスします。
組織の中でAWSのID集約を行う場合、様々なしがらみが少なくすぐに採用しやすいのがJumpアカウント方式です。この方式のメリットを以下に列挙します。
AWS外部のID基盤と連携する必要がなく、AWS環境だけで独立してIDの集約管理ができる
マルチアカウント管理のためのAWS Organizationsを利用しなくてもアカウントをまたがったアクセス制御ができる
永続的な認証情報が必要なIAMユーザーを1箇所に集めることでリスクのあるIDの管理を楽にできる
Jumpアカウント以外のAWSアカウントでIAMユーザーを禁止できる
利用者のAWSに対する認証情報を1つに絞り、多数の認証情報を管理する必要を無くせる
JumpアカウントのIAMユーザーは必ずスイッチロールして別のAWSアカウントで利用するためだけに利用し、利用者のIAMユーザーはJumpアカウント上ではスイッチロールに必要なAssumeRole権限のみ保持している状態とします。また、MFAを利用しなければAssumeRoleもできないように設定します。これにより、万が一MFAすら突破されてIAMユーザーが不正に利用されたとしても、Jumpアカウント上では何もできず、別のAWSアカウントについての情報も無いため悪用が難しい構成となります。これが現代のIAM管理の最低限の要件です。
Jumpアカウントを実現するために、各IAMユーザーには以下の2つのポリシーを適用します。
1つ目は他のAWSアカウントにスイッチロールすることを許可するポリシーです。
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "*"
    }
}
2つ目はIAMユーザーが自身のMFA認証の設定とマネジメントコンソールのパスワード変更を許可するIAMポリシーです。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListActions",
            "Effect": "Allow",
            "Action": [
                "iam:ListUsers",
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIndividualUserToListOnlyTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListMFADevices"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/*",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToManageTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToDeactivateOnlyTheirOwnMFAOnlyWhenUsingMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ],
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        },
        {
            "Sid": "AllowGetAccountPasswordPolicy",
            "Effect": "Allow",
            "Action": "iam:GetAccountPasswordPolicy",
            "Resource": "*"
        },
        {
            "Sid": "AllowChangePassword",
            "Effect": "Allow",
            "Action": "iam:ChangePassword",
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "BlockMostAccessUnlessSignedInWithMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ListUsers",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "iam:GetAccountPasswordPolicy",
                "iam:ChangePassword"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ],
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

この2つのポリシーにより自身のMFAの設定ができるようにしつつ、それ以外の操作は別のAWSアカウントにAssumeRoleしかできないようになります。Jumpアカウントを採用する際のポリシーの詳細はJumpアカウント環境でIPアドレス制限を行う方法 | DevelopersIOのIP 制限なしの Jump アカウント設定をご確認ください。
IDの集約方法を決めたら、IAMユーザーを徹底的に無くすことを考えましょう。IAMユーザーはアクセスキーを作成して永続的なクレデンシャルとして利用されるため、リスクが非常に高いです。基本的にはIAMロールを利用するために、徹底的にIAMユーザーを無くしていくことが必要です。IAMユーザーを無くすためには、特に開発者に対するフォローが必要です。AWS IAM Identity Centerを利用している場合にはaws-sso-cli、SAMLの場合にはsaml2aws、Jumpアカウント方式ならAWSumeなどのツールがあるためこれらを活用した開発者体験の向上も合わせて実施しましょう。

最近ではAWS CloudShellもあり、ちょっとしたCLIやSDKの処理ならこちらでも代用できるようになりました。このあたりは極端に縛らなくていいように開放していきましょう。
また、組織の管理者としてはIAMを作成・管理する権限をいかに利用者に委譲していくかが重要です。開発者の作成するLambda用のIAMロールなどや、プロダクトのメンバー用のIAMロールなどを中央集権的にすべて払い出すことは限度があるため、適切な教育プロセスなどを挟んで権限委譲をする仕組みを検討しましょう。ビジネスの速度を阻害しない体制づくりが必要です。教育についてはまた後で触れます。
 4-3.ガバナンス機能AWSアカウント全体で最初から適用すべき様々なガバナンス機能について一通り触れていきます。AWSマルチアカウント管理の中では新規のAWSアカウントを発行する際に一通りの機能を有効化する発行フローを整備することが重要です。AWSではこの新規AWSアカウント発行フローを執り行う仕組みをアカウントベンディングマシンと呼びます。例えばCloudFormationのテンプレートを用意しておき、AWSアカウントを作成したら毎回実行する操作を定義しておくところから始められます。理想はAWS OrganizationsやAWS Control Towerを利用してまとめて管理し更新できるところまでできるとよいですが、簡単ではありませんので目指す姿として考えておきましょう。
ここでは以下のガバナンス機能について解説します。
AWS CloudTrail
AWS Config
Cost
Amazon GuardDuty
AWS Security Hub
IAM Access Analyzer
 4-3-1.AWS CloudTrailAWS CloudTrailはAWS環境で実行するAPI操作のログを記録します。AWS環境で必須のログとなるのですべてのAWS環境でまずCloudTrailの証跡の作成を行う必要があります。一括で全リージョンのログを1つのS3バケットに集約する設定が可能です。基本的にAWSアカウント上でログを見るときは集約されているべきですのでまとめておきます。
一方で、AWS Organizationsを利用する場合や、マルチアカウントでの管理をするときにログ集約用のS3バケットにすべてのAWSアカウントのログを集約する方法も検討できます。しかしこれは分析やログの保全のために必要に応じて設定する程度で、必須ではありません。どちらかといえばログが消えないようにするために、保存先のS3バケットでオブジェクトロックの設定を行うか検討するほうが大切でしょう。オブジェクトロックはS3の上書きを防ぐための機能で、ログの上書きや削除を防止できます。詳細はS3 オブジェクトロックの使用 - Amazon Simple Storage Serviceを確認してください。
保存されたログを分析する場合はAmazon Athenaを利用します。例えば「誰がこのEC2インスタンスを作成したのか？」「いつこのユーザーがログインしたのか？」などの分析が可能です。分析のための設定は【全リージョン対応】CloudTrailのログをAthenaのPartition Projectionなテーブルで作る | DevelopersIOが参考になります。
単体のAWSアカウントで利用するAWS CloudTrailの証跡の設定以外にも、組織でまとめてログを集約し、一緒に分析もできるようにするCloudTrail Lakeという機能もありますが、現状必要がなければ、コストの兼ね合いもあるので利用する必要はありません。
 4-3-2.AWS ConfigAWS Configは各AWSリソースの変更履歴を管理するサービスです。AWS CloudTrailはAPI実行履歴でしたが、その結果リソースにどのような変化があったかを、リソース基準で管理ができます。そのリソースがいつどのような設定に変わったか、変更管理を行う上で重要な機能でこれもAWSを利用するには必須のログです。
AWS ConfigはAWS CloudTrailと異なりリージョンごとに有効化する必要があります。一つ一つをAWSマネジメントコンソールから手動で実行すると大変なので、こういうときはAWS CloudFormationのStackSets機能を利用して、全リージョンに一括展開しましょう。詳細は[小ネタ]CloudFormation StackSetsでConfigを全リージョン有効化しつつグローバルリソース記録は特定のリージョンのみで有効化する | DevelopersIOを参考にしてください。

さらに、すべてのAWSアカウントでこれを展開する場合も、StackSetsを応用すれば可能です。
AWS Configには、各AWSリソースの変更履歴を記録するだけではなく、その変更をイベントトリガーとし、適切な設定であるか確認するConfig Rules機能があります。例えば、本来組織としては、Security GroupでSSHポートを0.0.0.0/0で許可する設定は禁止しているにも関わらず、あるタイミングでそれが許可されたら、すぐに検出することが可能です。変更管理を行うということは、このように組織のコンプライアンスを維持することにも活用できます。

Config Rulesは一つ一つのルールを整備することは大変ですので、まずは後述するAWS Security Hubの機能を活用したコンプライアンスチェックから始めるといいでしょう。そちらで物足りなく感じたら、追加で独自にConfig Rulesを設定していく運用を始めてください。
 4-3-3.Costコストを保護することもセキュリティの一環です。クラウドは特に従量課金の部分が大きく、利用者が常にコスト意識を持たなければいけません。

AWSでコストを管理するために利用できる機能はいくつかあります。AWS Budgetsは予算を設定し、例えばその予算経過50%や月次予算予測が100%を超えたらアラートを出すといった事ができます。
AWS Cost Explorerはコストの使用状況を詳細に分析することができます。AWS Cost Anomaly Detectionは機械学習モデルを使用して異常なコストが発生している場合に検出できます。それぞれ利用していきましょう。
 4-3-4.Amazon GuardDutyAmazon GuardDutyはポチッと有効化するだけでAWS上の様々な脅威を検出できるサービスです。クラウドでは様々なリソースを様々な使い方で利用します。管理する範囲が広く、気がつくと脅威にさらされていることがあります。AWS環境上ではそのような脅威にさらされた際にAmazon GuardDutyが検出してくれます。例えば、EC2がマルウェアに感染したり、IAMが不正に利用されたり、S3の情報が漏洩したりしたときに検出できます。
Amazon GuardDutyはすべてのAWSアカウントですべてのリージョンで有効化すべきサービスです。すべてのAWSアカウントに必要なのは、例えばセキュリティをそこまで強固にする必要のない、ちょっとした検証用のAWSアカウントであったとしても、悪用された場合の金銭的な被害は多いからです。AWSが不正に利用されれば、従量課金のため被害はどんどん拡大していきます。検証用のAWSアカウントであっても脅威にすぐに気付けなくてはいけません。すべてのリージョンというのは有効になっているすべてのリージョンを対象としています。攻撃者はAWSアカウントに侵入が成功した場合、高確率で常用しているリージョンを避けて悪用を始めます。利用していないリージョンでこそ脅威を検出する必要があります。もし利用していないリージョンでのセキュリティ強化コストを抑えたい場合には、AWS Organizationsの機能であるSCPを利用したリージョン制限を利用することを推奨します。
Amazon GuardDutyを有効化してから運用までは[2021年版]Amazon GuardDutyによるAWSセキュリティ運用を考える | DevelopersIOを参照してください。

もし有効化してから検知がたくさんで続ける場合は、そもそもAWS環境がアンセキュアであるということですから、アーキテクチャの見直しをしましょう。
 4-3-5.AWS Security HubAWS Security HubはAWS Configを利用してAWS上の各種設定がセキュアであるかチェックするサービスです。前述のようなSecurity GroupのSSHポート開放の他にもIAMユーザーのMFA未設定、S3の公開設定、ALBのログ未設定など幅広いAWSサービスの設定がチェックできます。
AWS Configではこれらの設定を個別に行う必要がありましたが、AWS Security Hubではスタンダードとしてチェックすべき項目をまとめて設定できます。いくつかのスタンダードがありますが、特に要件がなければまず「AWS基礎セキュリティのベストプラクティス(AWS Foundational Security Best Practices)」の利用を強く推奨します。AWSによりメンテナンスされ、新しいサービスや機能にも追随するスタンダードです。これを、Amazon GuardDutyと同じようにすべてのAWSアカウントのすべてのリージョンに展開していきましょう。

有効化から運用は[2021年版]AWS Security HubによるAWSセキュリティ運用を考える | DevelopersIOを参照してください。

スタンダードを有効化することで、各項目の達成率をセキュリティスコアとして算出します。最初はセキュリティスコアが低くて改善が大変なこともあるかもしれません。しかし見つかった設定の問題はどれも改善していくべき項目です。項目についての対応を検討したら、それを社内のガイドラインに落とし込むことを推奨します。セキュリティスコアを100%に維持することは大変ですが、しっかり100%を目指して現実的な運用に落とし込みましょう。
 4-3-6.IAM Access AnalyzerIAM Access Analyzerは外部公開しているリソースを検出できる機能です。IAMと名前がついていますが、IAMロールだけでなく、KMSやRDSなど他の外部共有できるリソースについても検出できます。
これらのリソースは外部共有の設定ができますが、外部共有されていた場合意図して設定したのかが重要です。IAM Access Analyzerでは外部共有されているリソースの一覧を表示し、それが正しいか正しくないかを以下のように振り分けていくことが可能です。
もし意図せず設定していた場合、是正していくことが可能です。

IAM Access Analyzerは、この外部アクセスの検出機能は無料で利用できます。最近はこの他にも機能が追加されておりそちらは有料となっていますので、まずは外部アクセスの検出だけでも有効にしてください。IAMと名前がついていますがリージョナルサービスのため、すべてのリージョンで展開しましょう。

IAM Access Analyzerの詳細についてはAWS入門ブログリレー2024〜AWS IAM Access Analyzer編〜 | DevelopersIOを参照してください。
 4-4.データ管理AWSの全体管理者としてはまず以下の観点に取り組みます。
組織自体のデータ分類を整理しAWS環境にも適用する
データの保管場所の命名やデータのラベリングを行い保護する対象を明確化する
データへのアクセス制御を整備する
ビジネスに合わせたデータの可用性や耐久性を確保する
順に説明します。
AWSでは様々なデータストレージがあり、あらゆるデータを保管します。AWSに限らずですが、どこに何のデータが存在しているかを組織で適切に管理する必要があります。顧客の個人情報や社外秘や機密情報を扱うルールなど、データ管理の方法は組織内で共通化しておく必要があります。AWSの全体管理者として命名規則やアクセス制御などをAWS環境のルールとしても落とし込みましょう。
データを適切に管理するには、まずデータを分類し、組織で守るべきデータを明確化し、どこにそのデータを保管しているかわかるようにしていきます。

例えば社外秘のデータをS3に保存する場合を考えてみます。まずAWSアカウント単位で扱えるデータの種類を定義して社外秘を扱うAWSアカウントを限定したり、S3バケットやS3オブジェクトの命名規則で社外秘が保管されているか明確化したり、タグでオブジェクトが社外秘かラベリングしたりします。
本番環境のデータを複製してテストデータに用いることはしてはいけません。この場合適切なラベリングもされず、扱うレベルが変わってしまいます。その結果、漏洩事故にもつながるでしょう。
データへのアクセス制御もデータ管理における重要な要素です。例えば顧客データを含むRDSを管理しているAWSアカウントでは、そもそもIAMユーザーやIAMロール自体を必要最小限にし、開発環境と同じように開発者に全権を与えるべきではありません。また、IAMを利用したRDSへのアクセスを制限し、RDSのデータを別のAWSアカウントに複製するなどの持ち出しを防ぎます。RDSの場合にはAWSレイヤーとは別にアプリケーションレイヤーでDBユーザーによるアクセス制御も組み合わせて行います。複数のレイヤーでそれぞれのアクセス制御を適切に行なっていく必要があるので見逃さないようにしましょう。
扱うデータに合わせた可用性や耐久性の設計が必要です。ビジネスクリティカルなアプリケーションやデータの場合、1AZで障害が起きてもサービスが止まらないようにしたり、日本のリージョンが大災害で被害を受けてもデータをロストせず24時間以内に復旧できるようにするなど考慮する必要があります。例えばRDSをマルチAZで冗長化して可用性を確保したり、S3の機密情報をクロスリージョンレプリケーションでリージョンレベルの障害が起きても保持できるようにします。可用性や耐久性の設計は基本的に組織のBCDRの設計に合わせて行います。AWSではDR戦略として大きく4つのアプローチ(バックアップ&リストア / パイロットライト / ウォームスタンバイ / アクティブアクティブ)を紹介しています。詳細はクラウド内での災害対策オプション - AWS でのワークロードの災害対策: クラウド内での復旧を確認してください。
 5.利用者にやってもらうことAWS全体の管理だけではセキュリティを保つことはできません。すべてのステークホルダーがAWSセキュリティに関わる必要があり、特に実際にAWSを利用してシステムやアプリを構築運用する事業部門にやってもらうこともいろいろあります。ここではAWS全体管理者とAWS利用者との関係性において、利用者にやってもらうことと全体管理者との関係性について説明します。以下の項目を扱います。
システムとアプリのセキュリティ対策
方針やルールに従い学習する
ガバナンス機能の運用
全体管理へのフィードバックとコミット
 5-1.システムとアプリのセキュリティ対策全体管理を行った先に、実際のビジネスを執り行うシステムやアプリが構築され運用されます。組織の規模や状態によりAWSの全体管理としてどの程度システムやアプリのセキュリティ対策に踏み込むかのレベル感は変わります。あまり全体管理側が成熟していない場合、これらは事業部門側で実施することが多くなります。ある程度成熟してくると、標準的な設計方針やサンプルなどが充実し、共通化できる運用が全体で管理され、事業部門の実行範囲が軽くなりよりビジネスに集中できます。

全体管理としてはまず最初に以下の項目を事業部門に実行してもらうところから始めましょう。
セキュアなAWS環境の設計と利用
インベントリの収集と脆弱性管理
セキュアな開発フローとアプリケーションの保護
 5-1-1.セキュアなAWS環境の設計と利用利用者にはAWS環境をセキュアに使って貰う必要があります。まずは初めてAWSを使うときのセキュリティ覚書〜利用者編〜 | コラム | クラウドソリューション｜サービス｜法人のお客さま｜NTT東日本の内容を理解し実践してもらいましょう。AWSを利用する際には各種アクセス制御を適切に設計運用していく必要があります。利用者編にある全体的なアクセス制御を簡単にまとめると、インターネット等の外部に面する箇所を最小にし、適切な認証認可のもと必要最低限の人が利用できるように意識する、ということです。
加えて、アクセス制御以外の要素も押さえていく必要があります。
システムの可用性も確保しなければなりません。VPC上のリソースはマルチAZで構成し、障害が発生してもサービスの提供を維持できるように設計します。より高レベルの可用性が求められる場合には、複数のリージョンにシステムを展開して分散化したりリージョン単位の障害にも耐えられるようにする必要があります。このあたりはデータ管理で説明したものと同じく、基本的に組織のBCDRの設計に合わせて行います。全体管理者は事業部門がそれぞれ必要な可用性のレベルを認識し適切に取り組めるようにドキュメントを作成・案内したり、あるいは具体的なガイドラインに落としていきましょう。
事業部門で利用するIAMの払い出しはある程度全体管理側から委譲するでしょう。理想的には適切なルールのもと、ほとんどのIAM操作を事業部門側に委譲することですが、最初はルールもないまま全権渡すか、逆に全部中央集権してしまいがちです。ルールがないまま全権を渡せばAdministratorAccess権限のIAMアクセスキーを作成してGitHubに公開してしまいますし、中央集権にすると開発者がEC2やLambdaに付与するIAMロールを利用したい時に毎回時間がかかりまともに開発が進みません。ルールと教育環境の整備をいち早く行い適切に委譲できるようにしましょう。まずはIAM でのセキュリティのベストプラクティス - AWS Identity and Access Managementにある内容などから最低限守るべき項目をピックアップして、全体管理者がルールを整備し、事業部門にルールを利用してもらうところから始めてみましょう。
 5-1-2.インベントリの収集と脆弱性管理システムやアプリを構築し運用する際には、どのようなミドルウェア・ソフトウェア・アプリケーションを利用しているか管理する必要があります。例えば以下のような情報が必要です。
EC2にインストールされているミドルウェア
httpdのバージョン
phpバージョン
phpライブラリのリスト
現在利用しているものとそのバージョンを確認することで現状を把握し、新しい脆弱性が出た際に影響範囲をすぐに確認することができます。EC2からこれらのインベントリ情報を収集できるのがAWS Systems Manager Inventoryです。AWS Systems Manager Inventoryにより以下のようにインベントリ情報が確認できます。
AWS Systems Manager InventoryはEC2にAWS Systems Managerのエージェントが入っていればデフォルトで収集できるため、すべてのEC2にAWS Systems Managerのエージェント導入を必須としましょう。始める場合にはAWS Systems Manager(SSM) インベントリを使ってインスタンスにインストールされているアプリケーションをチェックする | DevelopersIOも参照してください。
一方で日々新しく出てくる脆弱性情報を収集し、現環境に影響が無いか確認していく必要もあります。これはAmazon Inspectorで実行できます。Amazon Inspectorを有効化することでEC2だけでなくECRとLambdaに対しても既知の脆弱性が無いか確認することができます。脆弱性が発見された場合は、パッチの適用やライブラリの更新などを行い修復しましょう。
現状動作しているEC2に対してパッチを継続的に適用する場合、AWS Systems Manager Patch Managerを利用できます。AWS Systems Manager Patch Managerは定義されたパッチベースラインに基づき脆弱性対応などのセキュリティに関するパッチやバグフィックスのパッチなどを定期的に適用してくれる機能です。パッチ適用を手動ではなく自動で行いたい場合に活用できます。始める際には【脆弱性対応】AWS Systems Manager Patch Manager を使ったパッチ戦略の例 | DevelopersIOも参照してください。
AWS Systems ManagerもAmazon InspectorもAWSアカウント全体や組織全体で一括で適用していくことが可能な機能ですが、事業部門側の運用が必要不可欠です。これらの機能は利用できると判断した事業部門側から始めたほうが良いです。
 5-1-3.セキュアな開発フローとアプリケーションの保護セキュアにしていくのはAWS環境だけではありません。アプリケーションや開発フローもセキュアにしていく必要があります。極力開発フローを整備して自動化することで、新しい実装を迅速に展開しつつセキュリティを維持でき、人の手から離れてミスを無くせます。

理想としては、開発者のIDE上でセキュリティを含むチェックを行い、コードリポジトリでも脆弱性や設定ミスをチェックし、CI/CDで迅速に展開できるようにしつつここでも脆弱性や設定ミスをチェックし、最終的に実行環境もチェックして実際の環境でのセキュリティをモニタリングします。
引用: DevSecOps パイプラインを構築してみよう ! - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
例えば利用しているミドルウェアに新しい脆弱性が発見された場合、自動化されたデプロイのフローが存在すれば、ミドルウェアのバージョンを上げて開発環境へ展開、開発環境でのテスト、その後の検証・本番環境への展開まで1日かけずにスムーズに実行できます。環境に対する変更のデプロイが遅くなればなるほど、本番環境は脅威にさらされ続けます。
全体管理側から開発手法について制限する必要はありませんが、レガシーな開発が行われそうであれば、テコ入れする必要があるでしょう。
アプリケーションを保護する仕組みはガバナンス的にWAFを導入することで全体管理の中でも可能です。とはいえ、WAFはアプリケーションに合わせた構築と運用を行わなければ得られる効果は非常に限定的なので、事業部門が適切に運用できなければ意義は薄いでしょう。まずは事業部門側でAWS WAFのマネージドルールのリストを確認し、ルール名から自分たちのアプリケーションに適しているものを選択して適用し、アプリケーションへの影響が無いことを確認しつつ、不正なリクエストを検出できているか確認するところから始めていきましょう。AWS WAFの適用は、いざアプリケーションが外部からの攻撃などの脅威に晒された際に、構成を変えずにすぐにブロックを開始できる防御のためでもあります。重要なWebアプリケーションであればどちらにしろ導入していきましょう。アプリケーションの運用に特に強く結びつくため、全体管理側ではできることは少ないです。ただWAF運用はナレッジが必要なため、全体管理側でうまく現場から勘所を集められると良いでしょう。
 5-2.方針やルールに従い学習するAWSを利用するすべての利用者は、IAMユーザーのアクセスキーを作成してGitHubにパブリック公開してはいけないことを最初に学ばなければなりません。S3をパブリック公開してはいけないことも同様です。

そのような、「これはやってはいけません」「こうしましょう」という方針やルールを全体管理者は整備していく必要があります。そして利用者にはそれを守って貰う必要があります。どうすれば徹底できるでしょうか？

例えばチェックリストを利用するのは悪くありません。しかし、チェックする内容とマルバツが並んでいるだけのエクセルを運用するのは苦痛です。まず殆どの場合こういったチェックリストはコンテキストが抜け落ちて、「なぜそれをしなければいけないのか」がわからなくなります。そのためまず方針やルールをまとめたガイドラインなどが整備され、その中にコンテキストや代替策、必須なのか任意なのか、それを行う場合の方法や費用、やらない場合の判断基準などすべてを集約していきます。チェックリストによるチェックはAWS環境の場合、ほとんど自動的にチェックできます。AWS Security Hubにまかせて手動のチェックリスト運用は減らしていきましょう。
利用者に対する教育プランも定義していきます。例えば、AWSを利用し始める人はすべてAWS Cloud Practitioner Essentials (Japanese) (Na) 日本語実写版を受講すること、部署でAWSアカウントの管理者になったらAWS Identity and Access Management (IAM) Immersion Dayを受講してガイドラインのIAM管理者用の内容を熟知すること、とするなどそれぞれのレベルと職務に応じた内容を整備します。簡単に全体のレベルを引き上げる事はできませんが、最低限やってはいけないことやこうしてほしいことなどは盛り込んでいきましょう。
 5-3.ガバナンス機能の運用前述したAmazon GuardDutyやAWS Security Hubなど、組織全体に適用できるガバナンス機能を事業部門にも運用してもらいます。むしろ、アプリケーションに依存するところも多いので事業部門による積極的な関与が必要になります。

まずは各機能の通知が全体管理と事業部門両方で受け取れるようにしておき、相互に連携しながら対処していきましょう。

全体管理側では集約したナレッジが溜まっていき、全体管理側で処理すべき内容と事業部門に対処してもらう内容がわかるようになってくるのでそれらをガイドラインに反映していきましょう。
 5-4.全体管理へのフィードバックとコミットここまで出てきたものいずれも、全体管理側と事業部門側での連携が不可欠です。そして、これがうまくいかないと全体管理側は「事業部門はちゃんとルールを守ってくれない」と言い、事業部門は「全体管理は現場をわかっていない」となります。双方向に理解し合い歩み寄る必要があります。特に、AWS利用のケースでは現場側の方がナレッジを持っていることは多いでしょう。その場合必要なのは全体管理へのフィードバックとコミットです。お互い完全に分業してもうまくいきません。より適切な方へ便利な方へ意見を出したり、実際に仕組みを整備するところを事業部門側からも協力すべきです。これらの取り組みがいわゆるCCoEにつながり、より快適な全体管理が可能になります。
CCoEはやることがたくさんあります。詳しくはCCoEがやることについてまとめてみた | DevelopersIOをご確認ください。
 6.AWS管理のネクストステップここまでがこれからAWSを使う組織や使い始めた組織が最初に取り組むべきセキュリティ対策です。うーむ、非常に大変ですね。しかし必要なことです。1つずつ着実に取り組みましょう。

そして、ある程度できてきたら次のステップを考えていきましょう。ここまでの内容にも一部出てきていますが、組織が成熟してきたらより以下の内容を考えていく必要があります。
ガイドライン整備
様々なステークホルダーが利用する環境にはガイドラインが必要です
必須のこと・任意のことを記載したり背景やコンテキストを補完しましょう
フィードバックを受け入れ実用的な内容に調整しましょう

SSOの実現
ID管理とアクセス制御は情報セキュリティの基本です
AWS外も含めたID管理のための仕組みを整備しましょう

CCoE設立
クラウドに関わる業務は多岐にわたります
クラウドに習熟し組織全体を効率的に回すための組織を作りましょう

AWS Well-Architectedフレームワークの活用
ベストプラクティスは常に正しいわけではありませんが非常に役に立ちます
ドキュメントは膨大ですが継続して活用しましょう
まずは主要なメンバーでもくもく会をしてみるのもいいでしょう

AWSセキュリティ成熟度モデルの活用
AWSのセキュリティ強化をするにはどこまでできているかを知る必要があります
このモデルを活用すると9つのセキュリティカテゴリと4段階の成熟度で現在地がわかります
強化の優先度を意思決定するのに役立ちます


最後に、管理者は1人で務まるものではありません。より良い組織にしていき、より良いビジネスを行うために、周りを巻き込み組織全体を良くしていきましょう。