こんにちは！イーゴリです。

AWS環境のセキュリティについて、4回に分けて解説しています。ぜひ、前回までの記事もご覧ください。

④AWS環境のセキュアな運用方法（本記事）

運用フェーズ

運用フェーズ

AWSマルチアカウントの戦略

前回の記事の項目に書いた通り、AWSはマルチアカウント戦略を推奨しています。詳しくは下記の記事をご参考ください。

blog.serverworks.co.jp

マルチアカウント環境の管理は、アカウント数が増えるにつれて複雑さが増し、セキュリティやガバナンスの維持が難しくなります。そこで、AWS はこれらの課題を解決するために AWS Organizations と AWS Control Tower というサービスを提供しています。

docs.aws.amazon.com

一元管理の運用を行う

docs.aws.amazon.com アカウント間で環境を一元管理できるツールやサービスを使用して AWS Organizations、運用モデルを管理できます。などのサービスは、アカウントのセットアップのブループリント (運用モデルのサポート) を定義し、を使用して継続的なガバナンスを適用し、新しいアカウントのプロビジョニングを自動化することで AWS Organizations、この管理機能 AWS Control Tower を拡張します。

と

docs.aws.amazon.com
AWS Organizations と AWS Control Towerは、このマルチアカウント構造を AWS 環境に実装および管理するために使用できる 2 つのサービスです。 AWS Organizations では、アカウントを 1 つ以上のレイヤーで定義された階層に整理しOUs、各 OU に多数のメンバーアカウントを含めることができます。サービスコントロールポリシー (SCPs) を使用すると、組織管理者はメンバーアカウントに対してきめ細かな予防的コントロールを確立でき、メンバーアカウントに対してプロアクティブおよび検出的コントロールを確立するためにAWS Config使用できます。多くの AWS サービスはと統合 AWS Organizationsされ、委任された管理コントロールを提供し、組織内のすべてのメンバーアカウントでサービス固有のタスクを実行します。
このベストプラクティスを活用しない場合のリスクレベル: 高

AWS Organizations

AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。組織単位（OU）でアカウントをグループ化し、サービスコントロールポリシー（SCP）を適用することで、組織全体のセキュリティポリシーやコンプライアンスを統制できます。

Windows Serverを扱ったことがある方には理解しやすいかもしれません。なぜなら、AWS Organizationsの階層構造は Active Directory のそれとよく似ているからです。Active Directoryでは、組織単位（OU）に対してグループポリシー（GPO）を適用します。同様に、AWS OrganizationsでもOUに対してSCPを適用し、その中のAWSアカウントにルールや制限を適用します。

トップレベルに管理アカウント（ルートアカウント）が存在し、その下に複数のOUがあります。各OUにはメンバーアカウントが含まれており、管理アカウントからこれらのOUやアカウントに対してポリシーを適用します。これにより、組織全体で一貫したセキュリティとガバナンスを維持しながら、マルチアカウント環境を効率的に管理できます。

例えば、特定のサービスの使用を禁止するポリシーをSCPとして作成し、それを開発環境用のOUに適用することで、そのOU内のすべてのアカウントでそのサービスの利用を制限できます。これは、Active DirectoryでGPOをOUに適用してユーザーやコンピュータの設定を統制するのと同じ考え方です。

AWS Organizationsには、以下の2つの主要な機能があります。

①一括請求（Consolidated Billing）

複数のAWSアカウントの請求を一元化し、コスト管理を簡素化します。これにより、全アカウントの利用料金をまとめて確認でき、ボリュームディスカウントの適用も可能になります。

②組織のポリシー

①の機能に加えて、アカウントを組織単位（OU）で、サービスコントロールポリシー（SCP）を適用することで、セキュリティポリシーやコンプライアンス要件を統一的に管理できます。

参考記事：

blog.serverworks.co.jp

この記事では②について説明しましたが、請求だけを統一したい場合は①を選択してください。

AWS Control Tower

AWS Control Tower は、AWS Organizations を基盤としてマルチアカウント環境を簡単にセットアップ・管理できるサービスです。ベストプラクティスに基づいたガードレールを自動的に適用し、セキュアで統制された環境を迅速に構築できます。

ガードレール（Guardrails）は、AWS Control Tower が提供するプリセットのルールやポリシーで、セキュリティやコンプライアンスの要件を満たすために利用します。

参考記事：

blog.serverworks.co.jp

専用AWSアカウントの作成

マルチアカウント環境では、重要なイベントの見落としや分散管理による把握漏れが発生しやすくなります。このため、すべてのアカウントから重要なログを専用のAWSアカウントに集約する構成を採用するケースもあります。

例えば、以下のように用途別にログの保存先アカウントを分ける方法があります。

監査ログ（Audit Log）を専用アカウントAに保存する。
セキュリティイベントを専用アカウントBに保存する。

AWS IAM

アクセス権の定期的なレビューとローテーション

IAMポリシーやアクセスキーなどの認証情報は、一度設定したらそれで完了というものではなく、定期的な棚卸しと見直しが求められます。

定期的に以下の点を確認・実施することで、不必要な権限や古くなった認証情報の悪用リスクを低減できます。

SEC02-BP05 定期的に認証情報を監査およびローテーションする
省略
このベストプラクティスを確立しない場合のリスクレベル: 高 docs.aws.amazon.com

アクセス権や認証情報は、設定時には必要でも、時間が経つと不要になることが多いです。「使っていないけど、まあいいか」で放置された情報が、インシデント時に狙われやすい穴になります。実際のセキュリティ事故の多くは、「削除しておけば防げた」ものです。

定期的なレビューとローテーションは、セキュリティ運用の「日常のお掃除」のようなものです。大がかりなツールがなくても、小さな確認からでも効果があります。

未使用のIAMユーザーの認証情報を削除する（[IAM.8]）

[IAM.8] 未使用の IAM ユーザー認証情報は削除する必要があります。
このコントロールは、IAM ユーザーが 90 日間使用されていないパスワードまたはアクティブなアクセスキーを持っているかどうかをチェックします。 docs.aws.amazon.com

未使用の認証情報を放置すると、リソースやデータに対して第三者に悪用されるリスクが高まります。不要なアクセスを防ぐためにも、これは重要な対策です。

そのため、長期間利用されていない IAM ユーザーのパスワードやアクセスキーは定期的に棚卸しし、不要と判断されたものは速やかに削除することを強く推奨します。これは、「セキュリティインシデントが起きる前に潰せるリスクのひとつ」として、非常に効果的な対策のひとつです。

[IAM] > [ユーザー]をクリックし、[最後のアクティビティ]などをクリックすると、一番古い順から整理できます。

[セキュリティ認証情報] > [コンソールアクセスを管理] > [コンソールアクセスを無効にする]を選択し、[アクセスの無効化]をクリックします。

コンソールパスワードが「有効になっていません」になっていることを確認する。

アクセスキーの場合、[アクセスキー]の欄に移動し、使わないActiveなアクセスキーを探します。

[アクション] > [無効化]をクリックします。

ステータスが[Inactive]になっていることを確認します。

完全にアクセスキーを削除したい場合、アクセスキーのそばにある[アクション] > [削除]をクリックします。

完全にユーザーを削除したい場合、ユーザー名のそばにある[削除]をクリックします。

その他のSecurity Hubで確認すべき関連項目

[IAM.8] は SEC02-BP05 に特に深く関連するコントロールであるため、一例として取り上げましたが、他にも Security Hub の IAM コントロールには、認証情報のセキュリティ強化に役立つ項目がいくつかあります。

特に、MFA の有効化やパスワードポリシーの設定などは SEC02-BP05 に直接対応するものではありませんが、併せて確認することで、全体として IAM セキュリティのレベルを大きく底上げすることができます。

docs.aws.amazon.com

[IAM.5] コンソールパスワードを使用するすべての IAM ユーザーに対して MFA を有効にする必要があります

MFA を使用することで、パスワードやアクセスキーの不正使用に対する防御力が高まります。

参考記事：

blog.serverworks.co.jp blog.serverworks.co.jp

[IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があります

最も強力なアカウントであるルートユーザーの保護が重要です。

[IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です

弱いパスワードの使用を防止する基本的な設定です。

参考記事（多要素認証 (MFA)を設定/強力なパスワードを設定する）：

blog.serverworks.co.jp

アクセス許可を継続的に削減する

AWSのセキュアな運用を維持する上で、アクセス許可の最小権限（Least Privilege）を維持することは極めて重要です。ただし、一度最小権限を設定したとしても、環境が変化したり、運用が拡大することで権限が「古くなる」可能性があります。そのため、「継続的にアクセス権を見直して削減していく」という運用が求められます。

SEC03-BP04 アクセス許可を継続的に削減する
省略
このベストプラクティスを確立しない場合のリスクレベル: 中 docs.aws.amazon.com

リソースに対するアクセス権は「定義した瞬間」から古くなり始めると考えるべきです。運用や組織が変化する以上、アクセス権は放っておくと徐々に現実から乖離していきます。だからこそ、継続的な棚卸しは、セキュリティ運用の「健康診断」だと思っています。

IAM Access Analyzer や CloudTrail＋Access Advisor を活用すれば、どの API コールが実行されたかを確認でき、不要な権限の特定に役立ちます。

IAM Access Analyzerで未使用なアクションや未使用のIAMロールを検出できる方法

[IAM] > [Access Analyzer] > [未使用のアクセス]をクリックします。

[アナライザーを作成]をクリックします。

[未使用のアクセス分析]を選択し、必要に応じて、下記を変更します。

名前：任意のアナライザー名
追跡期間：デフォルトは90日ですが、1日～365日の範囲で変更可能です

[アナライザーを作成]をクリックします。

一定時間が経過すると、未使用のロールなどが表示されます。

対象をクリックしますと、詳細が見られます。

最終使用日が「決してしない」と表示されている項目は、「一度も使われたことがない」という意味ではなく、指定した追跡期間内で使用されていないことを意味しています。

過去のCloudTrailイベントに基づいて IAM ポリシーを生成できる方法

現在のユーザーに広範な権限が与えられている場合でも、IAM Access Analyzer を使えば、過去の CloudTrail の API アクティビティをもとに、自動的に IAM ポリシーを生成することができます。この機能を活用することで、実際に使用されたアクションだけを含む「最小権限（Least Privilege）ポリシー」を簡単に作成できます。

対象IAMロール/ユーザーを選択し、一番下にある [CloudTrail イベントに基づいてポリシーを生成] を展開し、[ポリシーを生成] をクリックします

次の画面で、必要な設定（期間やサービスなど）を指定し、再度 [ポリシーを生成] をクリックします

ステータスが「成功」になるまで待機します

[生成されたポリシーを表示] をクリックすると、最小権限ポリシーの案を確認できます

注意点：

この機能で生成されたポリシーは、そのまま使うのではなく「参考」として使うのが基本です。たとえば、EC2 の管理コンソールを開くだけで複数の API コールが自動的に発生しますが、実際に必要なアクションはごく一部です。一つひとつのアクションの意図を確認したうえで取捨選択しましょう。
生成されたポリシーの中には、変数表記のARNが含まれていることがあります。これらはそのままでは使用できないため、実際の値に置き換える必要があります。

arn:aws:ssm:${Region}:${Account}:association/${AssociationId}

内容をコピーして手動で編集することもできますし、[次へ] をクリックしてウィザード形式で最後まで進めることも可能です。

また、対象の IAM ロールまたはユーザーの画面で [最終アクセス日時] をクリックすると、似たようなアクセス状況を確認することもできます。

[Filter by services access history] を使えば、サービスごとの「アクセスあり」「アクセスなし」のAPIコールを視覚的に確認できます。

ライフサイクルに基づいてアクセスを管理する

SEC03-BP06 ライフサイクルに基づいてアクセスを管理する
省略
このベストプラクティスが確立されていない場合のリスクレベル: 中 docs.aws.amazon.com

リスクレベルは「中」とされていますが、個人的には不要な認証情報の削除は非常に重要な運用と考えており、本記事で取り上げました。

IAMユーザーやロールなどのアイデンティティは、一度作成したらずっと必要というわけではありません。例えば、以下のようなケースでは定期的な見直しと削除・無効化が必要です

退職・異動したユーザーのIAMアクセスが残っている
使われなくなったクロスアカウントロールが放置されている
一時的に作成されたIAMロール（例：PoC用など）がそのまま本番環境に存在している

アクセスの棚卸しを「イベントベース」（例：退職・異動）だけでなく、定期的なライフサイクルチェックとして実施することで、不要な権限の温床を減らすことができます。

運用に組み込む例としては下記と考えられます。

IAM Access Analyzer で「未使用のアクセス」（後ほど紹介）を定期的にチェックする
AWS Config ルールを使って、「使用されていないIAMユーザー」や「長期間使われていないアクセスキー」などを検出する
AWS Organizations を使って、OU単位でライフサイクル管理方針（自動化など）を統一する

バックアップ

docs.aws.amazon.com

RPO/RTOを定義し、バックアップを取得する

バックアップを「とりあえずやっておく」だけでは、いざという時に業務を正常に復旧できる保証はありません。そのため、まずは RPO（Recovery Point Objective：目標復旧時点）と RTO（Recovery Time Objective：目標復旧時間）を明確に定義することが重要です。

REL09-BP01 バックアップが必要なすべてのデータを特定してバックアップする、またはソースからデータを再現する
このベストプラクティスを活用しない場合のリスクレベル: 高 docs.aws.amazon.com データソースが識別され、重要性に基づいて分類されます。次に、RPO に基づいてデータ復旧戦略を確立します。この戦略には、これらのデータソースをバックアップするか、他のソースからデータを再生成する能力を持つことが含まれます。データを喪失した場合は、実装された戦略によって、定義された RPO および RTO 内でデータを復旧または再生成できます。

RPO（Recovery Point Objective：目標復旧時点）とは、「どの時点までのデータが復旧できれば問題ないか？」という指標です。例えば、RPOを1時間とした場合、1時間おきにバックアップを取得する必要があります。業務において「どれくらいのデータ損失までなら許容できるか？」という視点で考えます。

RTO（Recovery Time Objective：目標復旧時間）とは、「システムがダウンした場合、どれくらいの時間で復旧する必要があるか？」という指標です。例えば、RTOを30分としたら、障害発生から30分以内に復旧できる体制が求められます。技術的な設計よりも、ビジネス上の影響時間の限界を決めるようなイメージです。

「何を守りたいか」を最初に決めることが大切です。
　⇒ データベース？構成情報？ログ？EC2の状態？それぞれRPO/RTOが違います。

バックアップは「取る」だけでなく、「復元できるか」まで確認しないと意味がありません。　（このあたりは、後述の「バックアップの完全性確認」で詳しく書いています）

データの定期的な復旧及びバックアップの完全性確認

AWS Well-Architected Frameworkの「セキュリティ」の柱ではなく、「信頼性」の柱の話になりますが、セキュリティにとても関わってくると思いますので、この記事で話したいと思います。

例えば、ランサムウェアが特定のリソースのデータを暗号化してしまった場合、データをバックアップから復元しないといけないですよね。でもバックアップから必要なデータを確実に復元できる保証はありません。多くの企業がデータ復旧手順の定期的なテストを怠っており、その結果、危機的な状況下でバックアップからデータを復元できないことがありますので、ご注意ください。

REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する

期待される成果: バックアップからのデータを、十分に定義されたメカニズムを使用して定期的に復旧することで、ワークロードについて確立された目標復旧時間 (RTO) 内での復旧が可能であることを確認できます。バックアップからの復元により、オリジナルデータを含むリソースになり、破損したりアクセス不能になっていたりするデータがなく、目標復旧時点 (RPO) 内のデータ損失であることを確認します。
このベストプラクティスを確立しない場合のリスクレベル: 中 docs.aws.amazon.com

個人的な意見：上記のリスクレベルが「中」と評価されていますが、場合によってセキュリティ観点から見ると個人的には「高」だと思います。ITセキュリティにおいて、完璧なシステムは存在しません。どのシステムも攻撃の対象となる可能性があります。攻撃する側も防御する側も、時間とコストを考慮して動いています。そのため、どのデータがどの程度重要であるかを明確に定義することが不可欠です。特に重要なデータについては、定期的なバックアップと復旧のテストを行い、その完全性を確認することが重要です。このようなテストは少なくとも半年に一度、もしくは一年に一度行うことをおすすめします。

AWS外の例になりますが、昔、海外でオンプレミスシステムを担当した時に、私は直接関わっていないPJでしたが、下記のような経験があったので共有したいと思います。

メールサーバーの定期的なバックアップを取得しました→復元テストを行いました→実際に復元が必要な時が来のでメールサーバーを復元しましたが、メールサーバーの中身のデータを復元できませんでした！

理由：テスト時にメールサーバー自体の復元テストは行いましたが、中身まで見られるというテストは行いませんでした。対象のハイパーバイザーのバックアップと対象のメールサーバー製品の組み合わせでメールサーバーのバックアップの完全性はなかったです。↓

[PS] C:\Windows\system32>Get-MailboxDatabase -status | fl name, *backup*

Name                           : DB01
BackupInProgress               : True
SnapshotLastFullBackup         : True
SnapshotLastIncrementalBackup  :
SnapshotLastDifferentialBackup :
SnapshotLastCopyBackup         :
LastFullBackup                 : 01.01.2010 13:00:00
LastIncrementalBackup          :★ここに情報なかったので、注意するべきだった
LastDifferentialBackup         :★ここに情報なかったので、注意するべきだった
LastCopyBackup                 :★ここに情報なかったので、注意するべきだった
RetainDeletedItemsUntilBackup  : False

メールサーバー自体は復元できましたが、このようなテストは意味がなかったですよね。目的はメールサーバーの復元ではなく、メールサーバーのデータを復元することだったので、このようなパターンには十分注意が必要です。

私からの補足になりますが、上記のようなパターンにならないように、「何を復元したいか」を明確にして、バックアップの目標を定義しましょう。繰り返しになりますが、何のバックアップが必要か明示的に定義する必要があります。そして期待通り、バックアップから具体的なデータの完全性を確認できたか確認しましょう。

ランサムウェア対策用のバックアップを取得する

AWS が公開している具体的な統計はありませんが、ここでは Sophos 社の調査結果を参考にします。Sophos X-Opsによると、攻撃者の平均滞留時間（攻撃開始から検知までの時間）は、すべての攻撃で10日から8日に、ランサムウェア攻撃では5日に短縮されました。つまり、水曜日から金曜日（3日間）のバックアップを取得しても、攻撃者がすでにランサムウェアを配置し、すでにランサムウェア込みのバックアップがとれている可能性が高いです。このようなバックアップから復元してしまうと、ランサムウェアが再び実行され、無限ループのような事態を招く可能性があります。

何日間のバックアップを取得するべきか明確なアドバイスはないですが、下記の情報に基づいて判断するといいかもしれません。

個人的にはランサムウェアの対策として最低でも1-3週間前のバックアップが必要ですが、セキュリティ、コスト、パフォーマンスのバランスが重要だと考えていますので、会社の予算によって対策が異なると思います。　あくまでざっくりの一例としてはRTO/RPO用の頻度の高いバックアップを取得し、ランサムウェア対策のバックアップを週ごとにとって1-3週間前のバックアップ(合計：2-3個)を残すという対策です。

After analyzing Sophos Incident Response (IR) cases from January to July 2023, Sophos X-Ops found that median attacker dwell time—the time from when an attack starts to when it’s detected—shrunk from 10 to eight days for all attacks, and to five days for ransomware attacks. In 2022, the median dwell time decreased from 15 to 10 days. www.sophos.com

実際に「1万ドルから要求された」という話も聞いたことがあります。

どんなに小さな企業だとしてもランサムウェアで感染される可能性は全然あります。その上、実際に身代金を支払った組織のうちデータを取り戻せているのは、7社のうちわずか1社だけだそうです。

詳しくは下記の記事をご参考ください。

身代金支払い額
まず、最もわかりやすいコストである身代金の支払い額から見ていきます。身代金の要求額は大体1万ドルから数百万ドルの範囲で、これまでで最も高い要求額は7,000万ドルでした。多くの場合、身代金の要求額はターゲットとなる企業の年間収益に対する割合（大抵は約3%）で計算されます。全体的な被害額について専門家の話では、身代金の支払い額はランサムウェア攻撃の総被害額の約15%にすぎないと言われています。ここで何よりも重要なのは、実際に身代金を支払った組織のうちデータを取り戻せているのは、7社のうちわずか1社だけであるということです。 www.netapp.com

「アンチウイルスがあれば充分でしょう！」という方に、下記で少し細く説明します。

アンチウイルスであっても、ランサムウェアの作りが非常に賢く、アンチウイルスが役立たない可能性は全然あります。その時に助かるのはランサムウェアなしのバックアップだと思います。

①ランサムウェアの動作の一例：

あるプログラムを起動してしまうと、このプログラムが攻撃者のウェブサイトにアクセスし、そのサイトから暗号化用のプログラムがダウンロードされます。このプログラムは、自己暗号化のための無害なPGP暗号化ソフトウェアです。スクリプトは暗号化キーを生成し、ファイルの暗号化を開始します。このプロセスでは、ネットワークを通じた拡散は行われず、ローカルマシンおよびアクセス可能な共有リソース上のドキュメントファイルを探して暗号化します。

アンチウイルスソフトウェアはこのようなアルゴリズムに害を見出さず、ユーザー自身が自分のドキュメントを保護するために行った行為と見なします。

ただし、ユーザーには復号化キーが残らず、暗号化が終了されると、その復号のためのキーはシステムから削除されます。被害者が指定されたEメールアドレスに連絡するため、どのキーを使用すればファイルを復号できるかは攻撃者のみ知っています。

上記のソースはこちらとなりますが、外国語のため、Google翻訳を使うと、中身が分かると思います。

②ランサムウェアの動作の一例：

アンチウイルスを騙すために、ランサムウェアのシグネチャーを定期的に変えることで、アンチウイルスが変わったランサムウェアを見逃してしまう可能性が非常に高まります。

③攻撃者の行動一例：

攻撃者がアンチウイルスソフトウェア自体を無効化することができますので、アンチウイルスで何もかも解決できるというわけではありませんので、ご注意ください。

バックアップを保護し、暗号化する

バックアップは「取得する」だけでは不十分です。攻撃者に削除・改ざんされたり、外部に漏洩してしまったりしたら意味がありません。そのため、AWS Well-Architected Frameworkの信頼性の柱（Reliability Pillar）では、REL09-BP02「バックアップを保護し、暗号化する」というベストプラクティスが定義されています。

REL09-BP02 バックアップを保護し、暗号化する
このベストプラクティスを活用しない場合のリスクレベル: 高
docs.aws.amazon.com このベストプラクティスを活用するメリット: バックアップを保護することで、データの改ざんを防止し、データの暗号化により、誤って公開されたデータへのアクセスが防止されます。

保護（削除防止）

ランサムウェアや誤操作などによってバックアップが削除されることを防ぐ必要があります。

暗号化（情報漏洩対策）

万が一データが外部に漏れてしまったとしても、暗号化されていればリスクは最小限に抑えられます。

暗号化に関しては「実装手順」に書いてある通り、Amazon RDS / Amazon EBS ボリューム / Amazon DynamoDB / Amazon EFS に保存されているデータなどの暗号化を行いましょう。バックアップにアクセスするための最小特権のアクセス許可を実装しましょう。

保護（削除防止）について下記の項目をご参照ください。

AWS Backup Vault

AWS Backup Vault Lockは、バックアップボールト内のオブジェクトを意図しない削除や悪意のある削除ができないよう、バックアップボールトを保護できるようにする機能です。

詳細は下記の記事をご参考ください。

blog.serverworks.co.jp

Amazon S3オブジェクトロック

S3のオブジェクトロックは、S3内にある対象のオブジェクトが絶対に削除されないようにするための保護機能となります。

詳細は下記の記事をご参考ください。

blog.serverworks.co.jp

Amazon S3クロスリージョンレプリケーション

クロスリージョンレプリケーション（CRR）は、S3バケット内のオブジェクトを自動的に別リージョンのバケットに複製する仕組みです。万が一、あるリージョンが大規模障害や災害に見舞われた場合でも、別リージョンに複製されたデータを使って業務を継続することができます。

なお、Amazon S3 に対しては AWS Backup を利用することもできますが、高額な料金が発生する可能性がありますので、ご利用の際は十分ご注意ください。

参考記事：

blog.serverworks.co.jp

自動化できるものを自動化しょう

AWS Config ルール

自社のコンプライアンスポリシーに準拠しているかどうかを確認できます。

例えば、S3パブリックアクセス禁止ルールがある場合、Configルールを使用します。

AWSが提供しているマネージドルールを使えば、簡単に設定をチェックできますので、ぜひ活用してみてください。

運用に便利そうなConfigルールいくつか紹介します。

restricted-ssh
セキュリティグループで 0.0.0.0/0 など全世界からの SSH アクセスを許可していないかをチェック
誤って広い範囲に SSH を許可してしまっている設定を早期に発見できます。
ec2-security-group-attached-to-eni-periodic
セキュリティグループが Elastic Network Interface（ENI）に適切に関連付けられているかを定期的に確認
孤立したセキュリティグループの存在や管理ミスを減らすのに役立ちます。
s3-account-level-public-access-blocks
S3 のアカウントレベルでパブリックアクセスをブロックする設定が有効かどうかをチェック
企業全体で S3 のパブリックアクセスを防ぎたい場合に非常に有効です。
iam-user-no-policies-check
IAM ユーザーに直接ポリシーがアタッチされていないことをチェック（ポリシーはロールやグループにアタッチすることが推奨されます）
root-account-mfa-enabled
ルートアカウントに MFA（多要素認証）が有効かどうかをチェック
※ ルートアカウントはできるだけ使用を避け、MFA は必須です！
cloudtrail-enabled
CloudTrail が有効かどうかを確認（ログ取得がセキュリティの第一歩）
cloud-trail-encryption-enabled
CloudTrail ログが暗号化されているかチェック（KMS連携）
ec2-instance-no-public-ip
EC2 インスタンスにパブリック IP が付与されていないか確認（意図しない公開を防ぐ）
rds-storage-encrypted
RDS のストレージが暗号化されているかをチェック
s3-bucket-logging-enabled
S3 バケットにアクセスログ設定が有効かどうかを確認
s3-bucket-public-read-prohibited / s3-bucket-public-write-prohibited
S3 バケットがパブリックリード／ライトになっていないかをチェック（基本のS3対策）
acm-certificate-expiration-check
SSL証明書の有効期限切れを防止（指定した日数以内に期限切れになるものを検出）。
ACMで作成した証明書は自動更新されるが、インポートした証明書は手動更新が必要
ec2-volume-inuse-check
EBS ボリュームが EC2 インスタンスにアタッチされているかどうかを確認オプション：EBS ボリュームは、インスタンスの削除時に削除対象としてマーク

AWS Systems Manager

AWS Systems Managerを使うことでOSのパッチの適用も自動化できますし、AWS Configルールに沿っていないパラメーターを自動的に修正できます。

AWS Systems Manager Patch Manager

AWS Systems Manager Patch Managerを使うことでOSのパッチの適用が自動化できますので、脆弱性予防の対策になります。

Windowsの例になりますが、下記の記事をご参照ください。

blog.serverworks.co.jp

AWS Systems Manager Automation

Config ルールと合わせて、AWS Systems Manager Automationを使うことで、下記のような課題を解決できます。

例：

パブリックに公開されているS3バケットを検知(Config ルール: s3-account-level-public-access-blocks)し、該当のS3バケットが自動的に非公開設定に変更されます（SSM Automation）。
使っていないセキュリティグループを検知し(Config ルール: s3-account-level-public-access-blocks)、このセキュリティグループが削除される（SSM Automation）。
セキュリティグループで許可されているSSHを検知し(Config ルール: restricted-ssh)、このルールが削除される（SSM Automation）。

AWS Systems Manager Run Command

オンプレミスの環境では、複数台のサーバーに一括で設定を反映したり、パッチを適用したりするために Ansible のような構成管理ツールがよく使われます。Ansibleは、SSH経由でサーバーに接続し、事前に用意したプレイブックに基づいて一括操作を実行できます。

一方、AWS環境においては、AWS Systems Manager Run Command を使うことで、SSHなしで安全かつスケーラブルに同様の一括操作を行うことができます。

機能	オンプレミス（Ansible）	AWS環境（Run Command）
一括コマンド実行	プレイブックを用いた一括操作	ドキュメント＋パラメータで一括操作
対象サーバーの指定	インベントリ定義が必要	インスタンスID、タグ、リソースグループで指定可能
通信方式	SSH（22番ポート）	SSM Agent 経由（443番ポート）
セキュリティ制御	SSH鍵の管理・配布	IAMポリシー＋CloudTrailによる操作ログ記録
対象サーバーの指定	インベントリ定義が必要	インスタンスIDやタグで指定可能
エージェントの要否	不要（SSHベース）	必要（SSM Agentのインストールが必要）
学習コスト／操作性	YAMLベース、慣れが必要	AWSコンソール or CLIで直感的に実行可能
自動化連携	Jenkinsなどと組み合わせて実行	EventBridge・Automationと連携可能

AWS CloudFormation

AWS CloudFormationを使用して、セキュリティ設定をコードとして管理することができます。これにより、セキュリティ設定の標準化と再利用が容易になり、新しいインフラストラクチャの迅速な展開が可能になります。例えば、IAMロールの作成、セキュリティグループの設定、S3バケットのポリシー適用などをテンプレートで自動化できます。

または、AWS CloudFormationを使うことで、インフラストラクチャの再構築やリカバリを自動化するため、RTO（復旧時間目標）を短縮することができます。災害復旧シナリオでは、テンプレートを使用して迅速にインフラストラクチャを再展開できるため、ダウンタイムを最小限に抑えることが可能です。

CloudFormationの利点は、セキュリティ設定の管理だけでなく、運用の効率化やBCP（事業継続計画）の強化にもつながります。

もちろん、AWS CloudFormationに限りません。Terraformもとても便利なIaCなので、どちらを使えばよいか十人十色ですので、お客様に合う方法をお選びください。

Amazon CodeGuru Reviewer

前回の記事で、「リポジトリに（プライベートリポジトリを含めて）認証情報などを置かないこと、AWS Secrets Manager及びParameter Storeを使う。」と書いたのですが、注意していても、うっかり認証情報などをコードに含めたまま、リポジトリにアップロードしてしまうことはゼロではありません。そのためにコードに関わる部分に関してAmazon CodeGuru Reviewerを活用しましょう。

Amazon CodeGuru Reviewerは、コードを自動的に分析し、セキュリティ問題の可能性を検出するツールです。これには、秘密情報や認証情報の漏洩が含まれます。開発者が誤ってパスワードやアクセスキーなどの機密情報をソースコードに含めた場合、このツールは警告を発し、問題を修正するよう促します。

「間違ってもリポジトリから削除すればよいでしょう」と思っている方がいるかもしれませんが、場合によってこの動作は難しくなるかもしれません。下記の参考記事をご覧ください。一番良いパターンは最初から認証情報をリポジトリにアップロードしないことです。

（誰でもGitHubの削除済み・非公開リポジトリデータにアクセス可能）： trufflesecurity.com

訓練を行う

何かが発生してから「これから何をすればよいか」を考え始めるのでは、遅すぎます。事前に計画を立てておくことで、非常時にもすぐに、より適切な判断ができるはずです。たとえざっくりとした計画でも、何もないよりはずっと良いと思います。

インシデントの対応管理

AWS環境におけるセキュリティインシデント対応は、準備が9割と言っても過言ではありません。

難しく考えず、最初は下記のようなメモからでもOKです。

通知が来たら、誰が対応する？→ oncallエンジニア or SRE
まず何を確認する？→ CloudTrail、SSMセッション履歴、IAMのログイン履歴など
状況をどこに共有する？→ Slackの #incident チャンネル
必要に応じて通知する部署は？→ 情シス、経営層、CSチーム etc.

こうした「ざっくり対応フロー」があるだけでも、初動の精度とスピードが全然違います。

必要であれば、AWS Systems Managerでプレイブックを自動実行する例（SSM Automation）や、ChatOps連携の構成図なども追加可能です！

参考記事：

blog.serverworks.co.jp aws.amazon.com

通知を設定する

通知は設定する必要がありますが、誤検知の通知や無視していい通知や対応しないといけない通知と混ざってしまうと、重要な通知を見逃してしまう可能性があるので、通知設計と通知の対応についてちゃんと考える必要があります。

スピアフィッシングの対策を考えよう

IT全体として非常に重要なことなので、あらためて説明させていただきます。

あるスピアフィッシング攻撃によってユーザーが油断してしまうと、たとえパスワードを強化していたり、MFA（多要素認証）を設定していたとしても、技術的な対策だけでは防げない状況になってしまいます。

「どうして！？」については下記で説明しますが、具体的な製品名は割愛します。

ステップ①：AWS(本当は攻撃者)から警告のメッセージがきました。メールですぐに何か対応しないといけないアクションを求めています。「例：どなたかがあなたの AWS アカウントに〇〇国/IP からアクセスしました。心当たりがない場合は、至急下記の URL をご確認ください。」のような上手なソーシャルエンジニアリング的な文章が書いてあります。

ステップ②：焦って、攻撃者のメールにあるログイン/PWリセットなどのURLをクリックします。メールのURLをクリックすると、AWSのようなページにリダイレクトされますが、実際はこれが攻撃者のページです！攻撃者がAWSのログインページを完全にコピーしましたので、見た目で本当のページかどうか判断できません。もちろん、細かくURLを確認すれば aws.amaz0n.com ※のように「おかしな表記」に気付ける可能性もありますが、多くの人はそれを見落としてしまいます。

※1 メールアドレスのなりすまし（改ざん）については、ここでは説明を省略します。
※2 記事執筆時点で amaz0n.com はAmazonの所有であることを確認しましたが、あくまで例示目的で使用しています。
※3 その他の例として、amazon.任意ドメイン名.com のようなURLにも注意が必要です。

被害者がパスワードを入力し、多要素認証も実行してログインします。すると、その認証情報が攻撃者の手に渡ってしまいます。

攻撃者が仕掛けた偽サイトでは、入力されたパスワードが正しいかどうかを確認できるため、パスワードや多要素認証が正しければ、そのまま実際の AWS マネジメントコンソールにリダイレクトされます。その結果、被害者は一切違和感を覚えることなくログインしたと感じてしまいます。

「でもね、俺のパスワードを知られてもMFAコードが変わるので、結局不正ログインは無理じゃないか？！」という考え方もあると思いますが、ここで詳しく説明させて頂きます。

ユーザーがパスワードやMFAを入力した後、毎回認証情報を再入力しなくても済むように、実際のWebページはユーザー（被害者）のWebブラウザにセッションキーを送信します。このセッションキーがブラウザに保持されていれば、一定期間はパスワードやMFAの再入力なしで操作が可能になります。

通常であれば、これは問題のない仕組みですが、今回は攻撃者のリバースプロキシを経由して通信が行われたため、全てのトラフィックが攻撃者に見える状態になります。その結果、このステップでセッションキーが攻撃者に奪われてしまうのです。

ここから攻撃者は、被害者になりすまして AWS マネジメントコンソールにアクセスできるようになります。そして、被害者が持つ権限によっては、被害が大きく拡大する可能性があります。

たとえば、他のユーザーを作成できる権限があれば、新たなユーザーを作成し、別のリージョンで EC2 を構築できる権限があれば、EC2 インスタンスを立ち上げ、セキュリティ上の穴を作成できる権限があれば、意図的に設定変更を行うといった具合に、攻撃者は自由に操作できるようになってしまいます。

このような事態を防ぐためには、あらかじめ防御策を講じておくことが重要です。

例1：定期的に社内教育を行う
例2：IPアドレス制限を使ったアクセス制御

"Condition": {
  "IpAddress": {
    "aws:SourceIp": "XXX.XXX.XXX.XXX/32"
  }
}

Well-Architected Frameworkを定期的に実施しょう

セキュリティ対策は定期的な見直しと改善が欠かせません。AWSでは、それを支援するためのツールとして「Trusted Advisor」や「Well-Architected Tool」が提供されています。

Well-Architected Framework Tool

Well-Architected Framework Toolを活用することで、従来のようにスプレッドシートやドキュメントで手動管理するのではなく、AWSマネジメントコンソール上で体系的かつ継続的にセキュリティ評価を実施・管理することができます。

このツールを使えば、セキュリティの柱（Security Pillar）をはじめとした6つの柱に沿って、現在のアーキテクチャにどんな改善点があるかを可視化し、改善履歴を記録として残すことも可能です。

新しいサービスの導入や構成変更の際に、「現在の構成に問題がないか」をツールで確認し、改善アクションを具体的に洗い出すことができます。これにより、セキュリティ・運用・信頼性の観点での抜け漏れを防ぎ、チーム全体で同じ基準で環境を評価・改善できる仕組みを整えることができます。

構成変更時だけでなく、四半期に1回など定期的なチェックとしても非常に有効です。

なお、Trusted Advisor を有効化することで、Well-Architected Framework Toolと連携する形でより実践的なインサイトを得ることができます。Trusted Advisorの検出結果をもとに、Well-Architected Toolでのレビュー時に「具体的な改善点」として反映することで、形式的なチェックで終わらせず、実際のセキュリティ運用につなげることができます。

Trusted Advisorの有効化

AWS Trusted Advisorは、アカウント全体の設定やリソースに対して、セキュリティ・コスト・パフォーマンス・信頼性などの観点からチェックを行い、改善提案をしてくれるサービスです。

参考記事：

blog.serverworks.co.jp

※Business Supportプラン以上でフル機能が利用できますが、一部項目は無料でも使用可能です。

AWS以外のセキュリティ標準も積極的に取り入れる

AWS関連

AWS Well-Architected Framework

特に Security Pillar と Operational Excellence Pillar は、セキュアな運用に直結します。

AWS責任共有モデルの確認

一度確認しただけで終わりにするのではなく、定期的に見直すことが重要です。「何か問題が起きた場合、誰が責任を持つのか」という視点を意識し、改めてAWS責任共有モデルを確認したほうがよいと思います。

一例ですが、「EBSの暗号化は必要か？」と疑問に思ったときは、まず AWS の責任共有モデルを確認してみましょう。

blog.serverworks.co.jp

AWS CIS ベンチマーク（CIS AWS Foundations Benchmark）

AWSアカウントの初期設定や運用におけるセキュリティのベースラインが提供されます。AWS Config や Security Hub とも連携可能です。

国際セキュリティ標準を読む

国際セキュリティ標準を定期的に読んで、会社に役立ちそうなベストプラクティスを導入するという手段は大事です。

NIST SP 800-53 (必須) / 800-171 (任意)

NIST SP 800-53は、米国政府や公共機関向けのセキュリティ基準の中核です。AWS自身がセキュリティ基盤として参考にしているベストプラクティスであり、AWS Well-Architected Framework や Security Hub の多くのコントロールもこのフレームワークに準拠しています。

一方、NIST SP 800-171は、米国連邦政府と契約する企業向けのセキュリティ要件で、CUI（Controlled Unclassified Information）の保護が対象です。日本企業や一般の民間企業には直接の適用義務はなく、主に米国防総省（DoD）との取引や、CMMC（Cybersecurity Maturity Model Certification）対応が必要な企業に関係します。