AWSセキュリティ・不正請求対策で学んだこと
AWS環境について、セキュリティ・不正請求・証跡管理の観点から確認した内容をまとめる。
このメモは、対応状況を管理するためではなく、AWSを安全に運用するうえで何が大切かを整理するためのもの。
1. 全体所感
今回AWS環境を確認して、個人開発であっても、セキュリティ・不正請求対策・運用監視の観点がかなり大切だと感じた。
特に、GuardDuty / Security Hub / WAF / Budget通知 / CloudTrail / EventBridge は、それぞれ役割は違うが、AWSを安全に運用するうえで重要な仕組みだと学んだ。
AWSはアプリを動かすだけなら比較的すぐ使えるが、実際に運用するなら、
- 誰が何をしたかを追跡できること
- 不審な動きに気づけること
- 想定外の課金に早く気づけること
- 外部公開部分を守ること
- 異常時に通知が届くこと
まで考える必要がある。
今回の確認は、AWSを「構築する」だけでなく、「安全に運用する」視点を持つきっかけになった。
2. 認証情報の扱い
AWS運用では、認証情報の扱いがかなり重要だと感じた。
特に、長期アクセスキーはCLIやTerraformで使いやすい反面、漏えいしたときの影響が大きい。
管理権限を持つIAMユーザーのアクセスキーが漏えいすると、リソース作成・削除・設定変更など、広い範囲の操作ができてしまう可能性がある。
そのため、AWSではできるだけIAMユーザーの長期アクセスキーに依存せず、IAM Identity Center（SSO）やAssumeRoleなど、一時的な認証情報を使う考え方が大切だと学んだ。
特にSSOユーザーを整えておくことは、普段のログインや権限管理を安全にするうえで重要だと感じた。
IAMユーザーを直接作って長期アクセスキーで運用すると、誰がどの権限を持っているのか、どの認証情報が残っているのかが分かりにくくなりやすい。
一方で、IAM Identity Center（SSO）を使うと、ユーザーごとの権限セットを管理しやすくなり、MFAや一時的な認証情報を前提にした運用に寄せやすい。
個人開発であっても、AWSアカウントを長く使うなら、最初からSSOユーザーでログインする形を作っておく方が安全だと思った。
気づき
- 長期アクセスキーは便利だが、漏えい時のリスクが大きい
- AdministratorAccess は強力なので、常用には注意が必要
- rootユーザーは緊急時用として扱うべき
- MFAは最低限必要
- できるだけ短期認証に寄せた方が安全
- SSOユーザーを整えておくと、ユーザー管理や権限管理を安全にしやすい
3. CloudTrailの重要性
今回一番大きく感じたのは、CloudTrailの重要性。
CloudTrailは、AWS上で「誰が・いつ・何をしたか」を追跡するための基本になる。
Event historyでもある程度の操作履歴は確認できるが、保持期間や保存の自由度に制限がある。
そのため、本格的に運用する場合は、CloudTrail Trailを作成し、S3などにログを長期保管することが大切だと分かった。
気づき
- CloudTrailはインシデント調査の土台になる
- Event historyだけでは長期的な証跡として弱い
- 不正操作が起きたとき、ログがないと原因調査が難しい
- CloudTrailは「あとで入れる」ではなく、最初から入れるべきものに近い
4. 課金監視の重要性
AWSでは、セキュリティだけでなく不正請求対策もかなり重要。
アクセスキー漏えいや権限悪用が起きると、高額なリソースを勝手に作成される可能性がある。
そのため、AWS BudgetsやCost Anomaly Detectionを使って、想定外の料金増加に早く気づける仕組みが必要だと学んだ。
特に個人開発では、少額で運用しているつもりでも、設定ミスや不正利用によって一気に請求が増える可能性がある。
気づき
- AWSは使った分だけ課金されるため、異常検知が重要
- Budget通知は最低限入れておきたい
- Cost Anomaly Detectionは閾値や頻度の設定が重要
- 不正請求対策は「防ぐ」だけでなく「早く気づく」ことが大切
5. GuardDutyの役割
GuardDutyは、AWS環境内の不審な挙動を検知するためのサービス。
たとえば、不審なIPからのアクセス、通常とは違うAPI操作、認証情報の悪用が疑われる挙動などを検知するために使える。
個人開発でも、本番運用するAWSアカウントではGuardDutyのような脅威検知の仕組みがあると安心感が大きい。
気づき
- GuardDutyは不審な動きを見つけるための仕組み
- 自分でログを全部見るのは現実的ではない
- 検知結果を通知につなげることで初動が早くなる
- 有効化して終わりではなく、Findingsを見る運用が必要
6. Security Hubの役割
Security Hubは、AWS環境のセキュリティ状態をまとめて確認するためのサービス。
GuardDutyやConfigなどの情報を集約し、セキュリティ基準に対してどこに問題がありそうかを確認できる。
Security Hubを見ることで、単発の設定確認ではなく、AWS環境全体のセキュリティ状態を俯瞰できると感じた。
気づき
- Security Hubはセキュリティ状態のダッシュボードに近い
- HIGH / CRITICAL Findings は優先して確認したい
- 全部を一気に直すより、重要度の高いものから見るのが現実的
- 継続的な改善に向いている
7. WAFと外部公開部分の保護
AWSでWebアプリを公開する場合、外部からアクセスされる入口をどう守るかが重要。
CloudFrontやAPI Gatewayなどを使っている場合、WAFを組み合わせることで、よくある攻撃や不審なリクエストをある程度ブロックできる。
特にWebアプリは、インターネットに公開した瞬間から自分が想定していないアクセスも来る。
そのため、WAFのように入口部分で守る仕組みは大切だと感じた。
気づき
- 公開URLには想定外のアクセスが来る
- WAFは入口でリクエストを制御するための仕組み
- CloudFrontやAPI Gatewayと組み合わせると効果的
- アプリ側の対策だけでなく、インフラ側の防御も必要
8. EventBridgeの重要性
EventBridgeは、AWS内で発生したイベントを拾って、通知や自動処理につなげるためのサービス。
今回特に大切だと思ったのは、EventBridgeが「検知」と「通知・対応」をつなぐハブになること。
GuardDutyやSecurity Hubで異常を検知しても、それに気づけなければ意味が薄くなる。
EventBridgeを使うことで、特定のイベントが発生したときにSNS、Slack通知、Lambdaなどへつなげられる。
例
GuardDuty Finding
↓
EventBridge
↓
SNS / Slack / Lambda
↓
通知・自動対応
気づき
- 検知サービスは通知までつなげて初めて実用的になる
- EventBridgeはAWS内のイベントを扱う中心的な仕組みになる
- 通知先を決めておくことで、異常に気づくまでの時間を短くできる
- 将来的には通知だけでなく、自動隔離や一時停止などの対応にもつなげられる
9. 最初にやっておきたい最低限の対策
AWSのセキュリティ対策は範囲が広いため、最初からすべてを完璧にするのは難しい。
ただ、個人開発や小さなサービスであっても、最低限入れておきたい対策はあると感じた。
特に重要なのは、認証情報を守ること、ログを残すこと、課金異常に気づくこと、不審な挙動を検知すること。
これらは高度なセキュリティ対策というより、AWSを運用するうえでの土台に近い。
優先して確認したいこと
- rootユーザーにMFAを設定する
- IAM Identity Center（SSO）を設定し、普段はSSOユーザーで操作する
- IAMユーザーの長期アクセスキーを必要最小限にする
- AdministratorAccessを常用しない
- AWS Budgetsで予算通知を設定する
- CloudTrailを有効化し、証跡を残す
- GuardDutyを有効化して不審な挙動を検知する
- Security Hubで重要度の高い指摘を確認する
- 外部公開するWebアプリにはWAFの導入を検討する
10. 「検知」と「対応」は分けて考える
今回整理していて、検知できることと対応できることは別だと感じた。
GuardDutyやSecurity Hubを有効化しても、検知結果を誰も見なければ意味が薄くなる。
また、Budget通知を設定していても、通知に気づかなければ不正請求への初動が遅れる。
そのため、AWS運用では「何を検知するか」だけでなく、「検知したあとにどう動くか」まで決めておく必要がある。
考えておきたいこと
- 通知はどこに飛ばすか
- 誰が通知を見るか
- どの重要度ならすぐ対応するか
- 認証情報漏えいが疑われるとき、最初に何を止めるか
- 請求異常が出たとき、どの画面を確認するか
- ログをどこまで遡って確認できるか
個人開発であっても、簡単な対応手順をメモしておくだけで、異常時に慌てにくくなる。
11. 不正請求を完全に防ぐのは難しい
AWSの不正請求対策で大切なのは、「絶対に起きないようにする」だけを目指さないことだと思った。
もちろんアクセスキーを漏らさない、権限を絞る、MFAを入れるといった予防策は重要。
ただ、設定ミスや認証情報漏えいの可能性をゼロにするのは難しい。
そのため、予防に加えて、異常な利用に早く気づく仕組みを持つことが重要になる。
大切な考え方
- 漏えいしない前提ではなく、漏えいした場合も考える
- 高額リソースを作られたときに早く気づけるようにする
- 不要なリージョンやサービスを使わない
- 権限は必要最小限にする
- 通知を見落とさない運用にする
セキュリティ対策は「侵入されないようにする」だけでなく、「被害を広げない」「早く気づく」ことも含めて考える必要がある。
12. 不正請求時の免除について感じたこと
AWSで不正請求が発生した場合、AWSがどのような基準で請求を免除するかは、明確には公開されていない。
そのため、「この設定をしていれば必ず免除される」「この対応をすれば必ず請求が取り消される」とは言えない。
ただ、いろいろな事例や記事を読んでいて、AWS側が判断するときには、アカウント側で基本的なセキュリティ対策をしていたか、異常に気づいて早期に対応していたかも見られている可能性があると感じた。
たとえば、MFA、SSOユーザーの利用、長期アクセスキーの管理、CloudTrailの証跡、Budget通知、GuardDutyの検知、不要なリソースの削除などが整っているかどうかは、少なくとも「適切に運用しようとしていたか」を説明する材料にはなる。
もちろん最終的な判断はAWS側の個別判断になるはずだが、不正請求が起きたあとに相談する場面でも、普段からどのように守っていたか、いつ気づいて何を止めたかを説明できることは大切だと思った。
気づき
- 不正請求の免除基準は公開されていない
- 基本的な対策をしていたかどうかは、説明材料になる可能性がある
- 早期検知と早期対応は、被害を抑えるだけでなく、AWSへ相談するときにも重要になりそう
- 「設定して終わり」ではなく、通知に気づいて対応する運用まで含めて準備したい
13. 個人開発でも運用の視点が必要
個人開発では、アプリを作ることやデプロイすることに意識が向きやすい。
しかし、AWS上でサービスを公開する場合は、作った後の運用も考える必要がある。
特に、外部公開しているアプリは自分だけが使うものではなく、インターネット上の誰からでもアクセスされる可能性がある。
そのため、個人開発であっても、本番環境として扱うなら最低限の監視・通知・証跡管理は必要だと感じた。
今後意識したいこと
- 作る前に認証情報の管理方法を決める
- SSOユーザーで操作できるようにしておく
- デプロイ前に課金通知を設定する
- 公開前にWAFやアクセス制御を確認する
- 運用開始時点でCloudTrailを有効化する
- 定期的にSecurity HubやGuardDutyの状態を見る
- 不要になったリソースは早めに削除する
14. まとめ
AWSを使ううえで、セキュリティ対策は後回しにしがちだが、実際には運用の土台になるものだと分かった。
特に、認証情報、証跡、課金監視、脅威検知、外部公開部分の防御、通知の仕組みはそれぞれつながっている。
どれか一つを入れれば十分というより、複数の仕組みを組み合わせることで、異常に気づきやすくなり、被害を抑えやすくなる。
今回の学びを通して、AWSは「動けばよい」ではなく、「安全に動かし続ける」ことまで考えて使う必要があると感じた。
まずは小さくてもよいので、MFA、SSOユーザー、Budget通知、CloudTrail、GuardDutyのような基本的な対策から整えていきたい。