【初級向け】 AWS におけるセキュリティの考え方
コーヒーが好きな emi です。最近はカフェインを控えています。
近年、サイバー攻撃の脅威はますます深刻化しています。
国内の大手企業がランサムウェア攻撃を受けてシステムが長期間停止したり、クラウド環境の設定ミスを突かれて大量の個人情報が流出したりと、セキュリティインシデントのニュースをよく目にするようになりました。特にランサムウェアによる被害はデータを暗号化されるだけでなく、「身代金を払わなければ盗んだデータを公開する」という二重脅迫の手口も一般化しています。
こうした状況を受けて、セキュリティ対策の考え方も変化しています。従来の「侵入を防ぐ」という発想だけでなく、「侵入されることを前提に、いかに被害を最小化し、迅速に復旧するか」 という視点が重要になってきました。
実際、最近では AWS Backup Vault Lock や S3 Object Lock のような「一度保存したら誰も削除・変更できない」仕組みを最後の砦として活用するケースが増えています。たとえ攻撃者に管理者権限を奪われたとしても、Vault Lock で保護されたバックアップだけは消せない、この「消せないバックアップ」がランサムウェア対策の切り札として注目されています。
しかし、セキュリティ対策は「最後の砦」だけでは不十分です。多層防御（Defense in Depth） の考え方に基づき、AWS アカウントの保護からネットワーク、アプリケーション、データに至るまで、各レイヤーで適切な対策を講じる必要があります。
本ブログでは、AWS を利用する上で押さえておきたいセキュリティの基本的な考え方と、対策の全体像を紹介します。各サービスの詳細な設定手順は扱いませんが、「まず何を意識すべきか」を把握するための入門編としてお読みください。
AWS のセキュリティ
セキュリティを考えるときは「何を守らなければいけないのか？それを守らないとどういったリスクがあるのか？」を具体的に考えるとイメージがわきやすいです。（個人情報や顧客情報など？業務データ自体？など）
資産の洗い出しを行い、リスクベースで対応を考えていくとよいです。
AWS では責任共有モデルがあり、利用者が責任を持つべき場所が明確です。
利用するツールとしては Well-Architected フレームワークが活用できます。セキュリティの柱では様々な質問を活用して自身の環境のセキュリティを考察できます。
AWS のセキュリティ対策は、大きく 2 つに分けて考えると理解しやすいです。
- 1. AWS アカウント自体のセキュリティ対策
- 家に例えると「玄関の鍵」や「金庫の暗証番号」を守ること
- これを盗まれると、家の中のすべてを自由にされてしまいます。
- → IAM、CloudTrail、MFA などで対策
- 家に例えると「玄関の鍵」や「金庫の暗証番号」を守ること
- 2. 使用するシステムのセキュリティ対策（OS/アプリ）
- 家に例えると「窓の補強」や「防犯カメラの設置」
- 玄関の鍵が無事でも、壊れた窓から侵入されることがあります。
- → WAF、セキュリティグループ、GuardDuty などで対策
- 家に例えると「窓の補強」や「防犯カメラの設置」
各レイヤーで様々な対策が必要です。
1. AWS アカウント自体のセキュリティ対策
AWS アカウントを安全に運用するためには、適切なアクセス管理と監視体制の構築が必要です。主要なサービスとベストプラクティスの概要を紹介します。
1-1. IAM によるアクセス管理
IAM は、AWS リソースへのアクセスを安全に制御するためのサービスです。「誰が」「何に」「どのような操作を」できるかを細かく設定できます。
ルートユーザーの保護
ルートユーザーは AWS アカウントに対するすべての権限を持つため、特に厳重な保護が必要です。
- 日常業務でルートユーザーを使用しない：管理者権限を持つ IAM ユーザーまたは IAM Identity Center（IdC）のユーザーを作成し、日常業務にはそちらを使用する
- MFA（多要素認証）の有効化：ルートユーザーには必ず MFA を設定する（ハードウェアトークンまたは認証アプリを推奨）
- アクセスキーを作成しない：ルートユーザーのアクセスキーは作成せず、プログラムからのアクセスには IAM ロールを使用する
最小権限の原則
必要最小限の権限のみを付与することで、セキュリティリスクを低減します。
- 必要な権限のみを付与：業務に必要な権限だけを持つポリシーを作成する
- IAM Access Analyzer の活用：未使用の権限を特定し、ポリシーを最適化する
- 定期的な権限の見直し：不要になった権限は速やかに削除する
ただし、実際に運用していると最小権限の原則を厳密に守り続けるのは現実的ではない場合もあります。一人一人、リソース一つ一つに最小権限を常に割り当てられるのが理想ですが、実際には「明日から部署移動になった」「今日からこの権限も必要」「開発期間中はこの権限が追加で必要」…などのケースに柔軟に対応していくのは運用負荷が高いです。
自動で権限を割り当てる仕組みの実装や、グループごとにまとめて権限を付与する等のバランスを加味して運用を決めていく必要があります。
IAM ロールの活用
IAM ロールを使用することで、長期的な認証情報（アクセスキー）の管理リスクを軽減できます。
- EC2 インスタンスにはインスタンスプロファイルを使用：アクセスキーをインスタンス内に保存しない
- クロスアカウントアクセスにはロールを使用：他の AWS アカウントへのアクセスには AssumeRole を活用
- 外部 ID プロバイダーとの連携：SAML 2.0 や OIDC を使用したフェデレーションアクセスを検討
IAM Identity Center（旧 AWS SSO）の活用
複数の AWS アカウントを管理している場合、IAM Identity Center を使用することで、シングルサインオンによる一元的なアクセス管理が可能になります。
- 一元的なユーザー管理：複数アカウントのアクセス権限を一箇所で管理
- 既存の ID プロバイダーとの統合：Active Directory や Okta などと連携可能
- 一時的な認証情報の自動発行：セキュリティリスクの軽減
1-2. AWS CloudTrail による監査ログの取得
CloudTrail は、AWS アカウント内で行われた API コールを記録するサービスです。「いつ」「誰が」「何をしたか」を追跡でき、セキュリティ監査やコンプライアンス対応に利用できます。
1-3. AWS Config による構成管理とコンプライアンス
AWS Config は、AWS リソースの設定を継続的に記録・評価するサービスです。設定変更の履歴を追跡し、コンプライアンスルールへの準拠状況を確認できます。
Config ルールによる自動評価
AWS Config ルールを使用して、リソースが組織のセキュリティポリシーに準拠しているかを自動的に評価できます。
- マネージドルールの活用：AWS が提供する事前定義されたルールを使用
- カスタムルールの作成：組織固有の要件に合わせたルールを Lambda で作成
自動修復の設定
Config ルールに違反したリソースを自動的に修復する設定も可能です。
- Systems Manager Automation との連携：違反検出時に自動修復アクションを実行
- 修復アクションの例：パブリックアクセス可能な S3 バケットのアクセス設定を自動修正
1-4. AWS Organizations によるマルチアカウント管理
複数の AWS アカウントを運用している場合、Organizations を使用して一元管理することでセキュリティを強化できます。
サービスコントロールポリシー（SCP）
SCP を使用して、組織内のアカウントで実行できるアクションを制限できます。
- ガードレールの設定：特定のリージョンでのリソース作成を禁止
- 重要な設定の保護：CloudTrail の無効化を禁止するなど
これらの対策を組み合わせることで、AWS アカウント自体のセキュリティを多層的に強化できます。段階的にセキュリティレベルを向上させていきましょう。
2. 使用するシステムのセキュリティ対策
AWS アカウントの保護ができていても、その上で動くシステム自体に脆弱性があれば攻撃者に狙われます。家の玄関の鍵をしっかり守っていても、窓が開いていたり、壁に穴が空いていれば侵入されてしまうのと同じです。
オンプレミスでシステムを運用されていた方にはなじみ深い考え方も多いかと思います。
ここでは、システムを守るための各レイヤーでのセキュリティ対策の概要を紹介します。
2-1. アプリケーション層（L7）のセキュリティ対策
AWS WAF
AWS WAF（Web Application Firewall） は、Web アプリケーションへの悪意あるアクセスを検知・遮断するためのセキュリティサービスです。
従来のファイアウォールがネットワーク層（IP アドレスやポート番号）でアクセス制御を行うのに対し、WAF はアプリケーション層（HTTP/HTTPS 通信の内容）を検査します。SQL インジェクションやクロスサイトスクリプティング（XSS）といった Web アプリケーション特有の攻撃を防御できます。
以下のようなルールを用いて、「この通信は許可して通す」、「通さない」、「通すがカウントする」、などのアクションを設定できます。
- マネージドルール：AWS やセキュリティベンダーが提供する事前定義されたルールセットを利用可能
- カスタムルール：自社の要件に合わせた独自ルールを作成可能
- レートベースルール：同一 IP からの大量リクエストを制限し、DDoS 攻撃を緩和
2-2. ネットワーク層（L3/L4）のセキュリティ対策
セキュリティグループと Network ACL
AWS でネットワークセキュリティの基本となるのがセキュリティグループと Network ACL です。
| 項目 | セキュリティグループ | Network ACL |
|---|---|---|
| 適用範囲 | リソース単位 | サブネット単位 |
| ルールの種類 | 許可ルールのみ | 許可・拒否ルール |
| ステート | ステートフル（戻りの通信は自動許可） | ステートレス（戻りも明示的に許可が必要） |
| 評価順序 | すべてのルールを評価 | 番号順に評価、最初にマッチしたルールを適用 |
ベストプラクティスとしては以下のような点に注意して設定しましょう。
- セキュリティグループ は必要最小限のポートのみを開放する
- 0.0.0.0/0（全開放）は極力避け、送信元を限定する
- 用途ごとにセキュリティグループを分け、再利用しやすくする
AWS Network Firewall
Network Firewall は、VPC 向けのファイアウォール、IDS・IPS を提供するマネージドサービスです。セキュリティグループや Network ACL よりも高度な機能を提供します。
- ディープパケットインスペクション（DPI）：パケットの中身まで検査
- ドメイン名フィルタリング：特定のドメインへの通信を許可・拒否
- 侵入防止システム（IPS）：既知の攻撃パターンを検知・ブロック
AWS Shield
Shield は、AWS リソースを DDoS（分散型サービス拒否）攻撃から保護するためのサービスです。
以下二つのプランがあります。
| プラン | 料金 | 主な機能 |
|---|---|---|
| Shield Standard | 無料（デフォルト有効） | L3/L4 の一般的な DDoS 攻撃からの保護 |
| Shield Advanced | 有料（月額 $3,000〜） | 高度な攻撃検知、WAF 料金の吸収、24/365 DDoS 対応チームへのアクセス |
Shield Standard は、TCP SYN Flood、UDP Flood、ICMP Flood などの一般的な DDoS 攻撃を自動的に検出・防止します。すべての AWS ユーザーに無償で提供されています。
2-3. 脅威検知とセキュリティ監視
Amazon GuardDuty
GuardDuty は、AWS 環境内の脅威を自動検知するマネージドサービスです。機械学習と脅威インテリジェンス（インターネット上で収集された脅威に関する情報を集めたデータベースやサービスのこと）を活用し、不審な挙動を検出して通知します。
- 検知できる脅威の例
- 不正な API 呼び出しパターン
- 暗号通貨マイニングの兆候
- 悪意のある IP アドレスからの通信
- IAM 認証情報の漏洩・不正利用
- S3 バケットへの不審なアクセス
GuardDuty は有効化するだけで動作を開始します。まずは有効化して、どのような検出結果が出るか確認することをおすすめします。
AWS Security Hub（CSPM）
Security Hub は、AWS アカウント全体のセキュリティ状況を一元的に可視化・管理するサービスです。
- 主な機能
- セキュリティスコア：セキュリティ基準への準拠状況をスコアで表示
- 検出結果の集約：GuardDuty、Inspector、Config など複数サービスの検出結果を統合
- 自動修復：EventBridge と連携して、検出結果に対する自動アクションを設定可能
以下のようなセキュリティ基準に則って AWS 環境が設定・構築されているかを検出できます。
- AWS Foundational Security Best Practices（AWS 基礎セキュリティのベストプラクティス）
- CIS AWS Foundations Benchmark
- PCI DSS
Security Hub のセキュリティチェックには AWS Config が必要です。Config が無効の場合は、先に有効化してください。
2-4. その他の重要なセキュリティ対策
Amazon Inspector
Inspector は、EC2 インスタンスやコンテナイメージ、Lambda 関数の脆弱性を自動的にスキャンするサービスです。
- OS やミドルウェアの既知の脆弱性（CVE）を検出
- ネットワーク到達性の問題を検出
- 検出結果を重要度でランク付け
AWS Secrets Manager
Secrets Manager は、データベースの認証情報や API キーなどの機密情報を安全に管理するサービスです。
- 認証情報のハードコーディングを排除
- 自動ローテーション機能
- アクセスの監査ログ
AWS Certificate Manager（ACM）
ACM は、SSL/TLS 証明書のプロビジョニング、管理、デプロイを簡素化するサービスです。
- パブリック証明書を無料で発行
- 証明書の自動更新
- CloudFront、ALB、API Gateway などとの統合
2-5. バックアップと復旧対策
セキュリティ対策は「防御」だけでなく、「侵害された後にいかに復旧するか」も重要です。ランサムウェアに感染した場合、直近のバックアップだけでは感染中のデータしか残っていない可能性があります。平均潜伏期間は 24 日、長い場合は 2 ヶ月とも言われており、ある程度長期間のバックアップを保持することが重要です。
AWS Backup
AWS Backup は、AWS リソースのバックアップを一元管理するサービスです。
- EC2、RDS、S3、EFS など複数サービスのバックアップを統合管理
- バックアップスケジュールや保持期間をポリシーで定義
- Organizations と連携して、複数アカウントにバックアップポリシーを一括適用可能
- 別リージョン・別アカウントへのコピー：DR 対策も含め、クロスアカウントでバックアップを保全できる
Vault Lock と S3 オブジェクトロック
事業停止など最悪の事態を避けるため、削除・変更ができないバックアップの保持を検討しましょう。
- AWS Backup Vault Lock：バックアップボールト内のデータを削除・変更不可にする機能
- S3 オブジェクトロック：S3 に保存したオブジェクトを一定期間または無期限で削除・上書き不可にする機能
たとえ攻撃者に管理者権限を奪われたとしても、これらの機能で保護されたバックアップは消せません。ランサムウェア対策の最後の砦として活用できます。
おわりに
本ブログでは、AWS におけるセキュリティの基本的な考え方と、各レイヤーでの対策について紹介しました。
ここまで読んで「やることが多すぎる…」と感じた方もいらっしゃるかもしれませんが、すべてを一気に全部やろうとしなくても大丈夫です。
まずは「ルートユーザーの MFA 有効化」や「GuardDuty の有効化」など、すぐにできて効果の高いものから始めましょう。オンプレミスで実施していた対策があれば、それを AWS に置き換える形で進めるのもスムーズです。また、「侵害されたときの影響度」を基準に優先順位をつけ、影響の大きいところから対策していくのも有効なアプローチです。
セキュリティ対策は終わりのない取り組みですが、小さく始めて継続的に改善していくことが大切です。本ブログが、その第一歩を踏み出すきっかけになれば幸いです。
以下ブログも AWS の各レイヤーのセキュリティ対策について参考になりますので、ご参照ください。
本記事への質問やご要望については画面下部のお問い合わせ「DevelopersIOへのご意見」からご連絡ください。記事に関してお問い合わせいただけます。
参考
