AWSのセキュリティについて入門してみた

2026/02/18· wan0ri· Category: Tech

TL;DR

AWS セキュリティに入門するなら、いきなり GuardDuty や Security Hub から入るより、まずは IAM / ネットワーク / 暗号化 / ログの4本柱を押さえた方が理解しやすいです。
学習順としては、IAM → VPC / Security Group → KMS → CloudTrail / CloudWatch → Security Hub / GuardDuty の順が入りやすいと感じました。
既存環境の是正対応では、「設定値を直す力」だけでなく、「なぜそれを直すのか」「本当に直すべきなのか」を説明する力も重要でした。

はじめに

2026年4月から、大手損保向けの AWS 上に構築されたデータ蓄積・分析システムの運用保守案件にアサインされています。
この案件では、経営統合に向けて既存 AWS 環境のセキュリティ是正を進める必要があり、私はその是正対応を 1 人で担当しています。
対象サービスはかなり広く、たとえば以下のような AWS サービスが含まれています。

GuardDuty
KMS
EKS
DynamoDB
Athena
SQS
EMR
S3
Glue
SNS
Lake Formation
Network Firewall
CloudTrail
EC2
EBS
ECR
ELB
IAM
Lambda
CloudWatch
VPC
Security Hub

正直、最初から全部を深く理解していたわけではありません。
むしろ、既存環境のセキュリティ是正を進める中で、何から理解すればよいかを後追いで整理していった という方が実態に近いです。

この記事では、その経験を踏まえて、「AWS セキュリティに入門する体で、何から学習を進めると入りやすいか」 を自分なりに整理してみます。

前提: AWS セキュリティは「サービス個別の暗記」から入らない方がよい

AWS セキュリティを学ぼうとすると、つい Security Hub、GuardDuty、IAM Access Analyzer のようなセキュリティ系サービスから見たくなります。
ただ、実務で是正対応をしてみると、先に押さえるべきなのは以下でした。

誰が何をできるか
どこからどこに通信できるか
データはどう守られているか
何が起きたか後から追えるか

つまり、サービス名より先に、セキュリティの観点を4つに分けて捉えた方が理解しやすいです。
私はまず次の4本柱で考えるのが良いと感じています。

IAM: 認可
VPC / Security Group / Network ACL: 通信制御
KMS / 各種暗号化設定: データ保護
CloudTrail / CloudWatch Logs: 監査・追跡

この4つを先に押さえておくと、その後に GuardDuty や Security Hub を見たときも、
「何を検知しているのか」
「なぜこの指摘が出るのか」
がかなり読みやすくなります。

最初に学ぶべき1つ目: IAM

なぜ IAM から入るのか

AWS セキュリティで最初に押さえるべきは IAM だと思います。
理由は単純で、ほぼ全サービスに跨って影響するから です。
実務でも、以下のような論点はかなり頻繁に出ます。

IAM User をまだ使っていないか
ルートユーザーの扱いが適切か
不要に強い権限が付与されていないか
ロールの信頼ポリシーが広すぎないか
サービスロールの用途が曖昧になっていないか

最初に見るポイント

IAM Policy の基本
- Effect
- Action
- Resource
- Condition
IAM Role と IAM User の違い
Assume Role の仕組み
AWS managed policy と customer managed policy の違い
最小権限の考え方

この段階で最低限できるようになりたいこと

ポリシー JSON を見て、何を許可しているか大まかに読める
AdministratorAccess を安易に付ける危険性を説明できる
「人にはロールより SSO / フェデレーション寄り、サービスにはロール」という基本線を理解する

2つ目に学ぶべき: VPC と通信制御

なぜここが重要か

是正対応では、S3 や KMS のような“設定を見るだけ”で終わらないものがあります。
その中でも、通信制御は影響範囲が広く、事故にも直結しやすいです。
特に以下は頻出です。

Security Group が広すぎる
Network ACL の意図が不明瞭
インターネット公開の要否が整理されていない
VPC Endpoint を使うべき通信がインターネット側へ出ている
EKS / EC2 / ELB / Lambda の接続要件が曖昧

最初に押さえたい概念

VPC
Subnet（public / private）
Route Table
Internet Gateway
NAT Gateway
Security Group
Network ACL

学習のコツ

ここはサービス名より、通信の絵を描けるか が大事です。
たとえば、以下を口頭で説明できる状態を目指すと理解が進みます。

EC2 から S3 へ通信するとき、どう流れるか
private subnet 上のワークロードがインターネットへ出るとき、何を経由するか
Security Group と Network ACL の違いは何か

実務上の感覚

セキュリティ是正では、「とりあえず閉じる」だけだと業務影響が出ます。
そのため、 通信要件を理解した上で、必要最小限まで絞る という順番で考えるのが重要でした。

3つ目に学ぶべき: KMS と暗号化

なぜ暗号化が重要か

データ蓄積・分析基盤では、保存データの暗号化は避けて通れません。
実際に対象になりやすいのは以下です。

S3 の暗号化
EBS の暗号化
RDS や DynamoDB の暗号化
SNS / SQS の暗号化
ECR / Athena / Glue 周辺の KMS 利用

最初に理解したいこと

AWS managed key と customer managed key の違い
KMS Key Policy と IAM Policy の関係
暗号化 at rest / in transit の違い
キーのローテーション
誰がそのキーを利用できるか

学習時の注意点

KMS は「暗号化のON/OFF」だけで終わらず、権限の話と強く結びつく のが難しいところです。

たとえば、

暗号化は有効なのにアプリが復号できない
キーポリシーが厳しすぎて運用で詰まる
逆にキーポリシーが広すぎて統制が効かない

といったことが起きます。
なので、KMS は単独で見るより、IAM とセットで学ぶのが良いです。

4つ目に学ぶべき: CloudTrail とログ

なぜログを早めに押さえるべきか

セキュリティは、守るだけでなく後から追えることも重要です。
実務でも以下の観点が頻繁に出ます。

その操作は誰が実行したのか
いつ設定変更されたのか
API Call を追える状態か
ログ保存先が適切か
改ざん耐性や保管期間は十分か

まず学ぶべき項目

CloudTrail が何を記録するのか
Management events と Data events の違い
S3 へのログ集約
CloudWatch Logs との連携
メトリクスフィルタとアラームの基本

入門としての理解目標

CloudTrail が「AWS API の監査ログ」であると説明できる
ログがあるだけでは不十分で、見られる形・気づける形 にする必要があると理解する
ログ保管先の S3 バケット側にも保護が必要だと分かる

5つ目に学ぶべき: S3 を中心に代表的なサービスのセキュリティを見る

ここまで来たら、個別サービスに入っていくのが良いと思います。
その最初の題材としては S3 がかなり学びやすいです。

なぜ S3 なのか

利用頻度が高い
公開事故のイメージが湧きやすい
IAM、バケットポリシー、暗号化、ログなど複数観点が集まる

S3 で見るべきポイント

Block Public Access
バケットポリシー
SSE-S3 / SSE-KMS
バージョニング
アクセスログやイベント通知
ライフサイクルと保管制御

S3 を理解すると横展開しやすい

S3 をきっかけにすると、次のサービスにも展開しやすいです。

DynamoDB: 暗号化、アクセス制御
SQS / SNS: 暗号化、送受信主体の制御
ECR: イメージスキャン、リポジトリアクセス制御
EBS: 暗号化、スナップショット管理
Lambda: 実行ロール、環境変数、VPC 接続

6つ目に学ぶべき: Security Hub と GuardDuty

ここでやっと“セキュリティサービス本体”に入る

Security Hub や GuardDuty は重要ですが、個人的にはここから始めると少し抽象度が高いと感じました。
なぜなら、これらは 何かを守る土台そのもの ではなく、 土台の問題を検知・可視化する役割 が強いからです。

Security Hub で見ること

どのようなセキュリティ標準に基づいてチェックしているか
Findings の重要度
どのサービスの、どの設定が問題なのか
例外扱いにすべき項目の切り分け

GuardDuty で見ること

不審な API コール
異常な通信
脅威インテリジェンスベースの検知
検知結果をどうハンドリングするか

実務で重要だったこと

是正対応では、Security Hub の指摘をそのまま全部直せばよいわけではありませんでした。
たとえば、

その環境では本当に是正が必要か
業務要件上、すぐには変えられないか
代替統制でカバーできているか

を整理し、顧客と認識を合わせる必要がありました。
つまり、Security Hub は「正解を自動で教えてくれるサービス」というより、 是正対象を洗い出す起点 として使う方が実務感に近いです。

私ならこう学ぶ: AWS セキュリティの学習順

ここまでを踏まえると、今の自分なら以下の順で学びます。

Step 1. IAM

ポリシーの読み方
ロールの考え方
最小権限

Step 2. VPC と通信制御

subnet / route / NAT / SG / NACL
インターネット公開と閉域通信の違い

Step 3. KMS と暗号化

KMS の基本
各サービスの暗号化設定
キーポリシー

Step 4. CloudTrail / CloudWatch Logs

監査ログ
変更追跡
アラートの基本

Step 5. S3 を軸に個別サービスへ展開

S3
EBS
DynamoDB
SQS / SNS
Lambda
ECR

Step 6. Security Hub / GuardDuty

Findings の見方
是正優先度の付け方
例外判断の考え方

学習時に意識するとよかったこと

1. 「設定項目」を覚える前に「事故パターン」を知る

たとえば、以下のような観点です。

権限が広すぎる
通信経路が広すぎる
暗号化されていない
ログが残っていない
外部公開が想定外で有効になっている

この観点を先に持っておくと、個別サービスを見たときも理解しやすいです。

2. “なぜそれを直すのか” を言語化する

セキュリティ是正は、単に設定値を変更する作業ではありません。

なぜ危険なのか
何を防ぎたいのか
変更したときの業務影響は何か

を説明できないと、合意形成が進みにくいです。

3. 例外を扱う視点も持つ

実際の現場では、全項目を機械的に是正できるとは限りません。
そのため、

是正する
一時保留する
代替統制でカバーする
対象外とする

を分けて考える視点も必要でした。

30日でざっくり入門するなら

もし自分が改めて 30 日で AWS セキュリティに入門するなら、こんな流れで進めます。

1週目

IAM を重点的に学ぶ
ポリシー JSON を読む練習をする
S3 バケットポリシーとの違いも軽く見る

2週目

VPC、Security Group、Network ACL を学ぶ
public / private subnet の違いを説明できるようにする
図を書いて通信経路を整理する

3週目

KMS、S3 暗号化、EBS 暗号化を学ぶ
CloudTrail と CloudWatch Logs の関係を押さえる

4週目

Security Hub と GuardDuty を触る
Findings を読んで、なぜ検知されたかを調べる
自分なりの是正優先順位を付けてみる

まとめ

AWS セキュリティは対象サービスが広いため、最初は何から手を付けるべきか迷いやすいです。
ただ、実務で既存環境の是正対応をしてみると、重要なのはサービス名を片っ端から覚えることではなく、まず次の観点で整理することでした。

IAM: 誰が何をできるか
ネットワーク: どこからどこに通信できるか
暗号化: データをどう守るか
監査: 何が起きたか追えるか

この土台ができると、Security Hub や GuardDuty の指摘もかなり読みやすくなります。

私自身、今まさに既存 AWS 環境のセキュリティ是正を進める立場ですが、結局は 基本サービスの理解が一番効く と感じています。

今後は、今回触れた各テーマについて、

IAM
KMS
Security Hub
GuardDuty
S3

あたりを個別記事としてもう少し深掘りしていければと思います。

Topへ戻る