AWSのセキュリティ管理について

Posted at 2026-03-08

AWS のセキュリティ基礎 — 責任共有モデル・権限管理・セキュリティ・サポートを一気に理解する

はじめに

この記事では、AWS を使ううえで避けて通れない セキュリティと運用の基礎知識 を 3 つのテーマでまとめて解説します
「AWS を触り始めたけど、セキュリティ周りがよくわからない」「IAM って結局なに？」という方を対象にしています
この記事を読むと、責任共有モデルの考え方、IAM による権限管理、主要なセキュリティサービスがわかるようになります

前提知識としては、AWS の基本的なサービス（EC2、S3 など）の名前をなんとなく知っていれば十分です。

1. 責任共有モデル

そもそもの話

AWS を使うとき、「セキュリティは全部 AWS がやってくれるんでしょ？」と思いがちですが、実はそうではありません。AWS とユーザーでセキュリティの責任を分担する仕組みがあり、これを 責任共有モデル（Shared Responsibility Model） と呼びます。

「of」と「in」で覚える

責任の分担は、主にクラウドそのもののセキュリティとその中のセキュリティとで分かれています。
前者はAWSが、後者はユーザが責任を持ちます。

フレーズ	担当	意味
Security of the Cloud	AWS	クラウドそのもののセキュリティ
Security in the Cloud	ユーザー	クラウドの中のセキュリティ

たとえ話

賃貸マンションで考えるとわかりやすいです。

管理会社（AWS） — 建物の耐震構造、エレベーター保守、共用部の防犯カメラ、オートロックの整備
住人（ユーザー） — 自分の部屋の鍵の管理、窓の施錠、貴重品の保管、火の元の確認

建物がどんなに頑丈でも、住人が玄関を開けっぱなしにしたら意味がないですよね。

具体的な分担

領域	AWS の責任	ユーザーの責任
物理インフラ	データセンターの建物・電源・冷却・入退室管理	—
ハードウェア	サーバー・ストレージ・ネットワーク機器	—
仮想化基盤	ハイパーバイザーの管理・パッチ適用	—
OS	—（EC2 の場合）	パッチ適用・設定
ミドルウェア	—（EC2 の場合）	インストール・設定・更新
アプリケーション	—	開発・脆弱性対策
データ	—	暗号化・バックアップ・分類
アクセス管理	—	IAM ユーザー・ポリシー・MFA
ネットワーク設定	—	セキュリティグループ・NACL・VPC

サービスによって境界線が変わる

使うサービスによって、ユーザーの責任範囲が大きく変わります。これがこのモデルの重要なポイントです。

マネージドサービスを使うほど、ユーザーの責任は軽くなります。 RDS なら OS パッチは AWS がやってくれるし、Lambda ならサーバー管理自体が不要です。

よくあるインシデントと責任

やらかし	誰の責任？	なぜ？
S3 バケットを全公開にして情報漏洩	ユーザー	バケットポリシーの設定はユーザーの責任
IAM ルートユーザーが乗っ取られた	ユーザー	MFA の設定・認証情報の管理はユーザーの責任
EC2 の OS 脆弱性を突かれた	ユーザー	OS パッチの適用はユーザーの責任
データセンターが自然災害で停止	AWS	物理インフラの管理は AWS の責任

実際のセキュリティ事故のほとんどは ユーザー側の設定ミス が原因です。

2. 権限管理（IAM）

IAM とは

IAM（Identity and Access Management）は、AWS リソースへの 「誰が」「何に」「何をできるか」を管理する サービスです。AWS のセキュリティの中核を担うグローバルサービスで、すべてのリージョンで共通です。

IAM の 4 つの構成要素

IAM には覚えておくべき 4 つの要素があります。

要素	何か	たとえ話
ユーザー（User）	AWS を使う人やアプリケーション	社員証を持った従業員
グループ（Group）	ユーザーをまとめたもの	「開発部」「営業部」などの部署
ロール（Role）	AWS サービスやユーザーに一時的に権限を付与	「今日だけ経理部の権限を借りる」許可証
ポリシー（Policy）	「何を許可/拒否するか」のルール（JSON 形式）	「この部屋に入っていい」「この書類を見ていい」というルールブック

ルートユーザーと IAM ユーザーの違い

AWS アカウントを作成すると、最初に ルートユーザー ができます。これはすべての権限を持つ「神アカウント」です。

	ルートユーザー	IAM ユーザー
権限	すべて（制限不可）	ポリシーで制御可能
用途	アカウント作成時の初期設定のみ	日常の作業
推奨	日常使用しない	日常使用する
MFA	必ず設定する	設定を推奨

ルートユーザーは普段の作業には使わず、MFA（多要素認証）を設定してロックしておく のが鉄則です。

ポリシーの書き方

ポリシーは JSON 形式で「何を許可/拒否するか」を定義します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*"
        }
    ]
}

フィールド	意味	この例では
Effect	許可 or 拒否	Allow（許可）
Action	どの操作か	s3:GetObject（S3 からの読み取り）
Resource	どのリソースに対してか	my-bucket 内のすべてのオブジェクト

最小権限の原則

IAM で最も重要な考え方が 最小権限の原則（Principle of Least Privilege）です。

必要な権限だけ を付与する
「とりあえず AdministratorAccess を付けておこう」は絶対にやらない
迷ったら権限を絞っておき、必要になったら追加する

// やってはいけない例 — すべてのリソースにすべての操作を許可
{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
}

// 正しい例 — 特定のバケットへの読み取りだけを許可
{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
    ]
}

IAM ロールの使いどころ

IAM ロールは EC2 や Lambda などの AWS サービスに権限を付与する ときに使います。アクセスキーをコードに埋め込む必要がなくなるのが大きなメリットです。

# EC2 に IAM ロールを割り当てる
aws ec2 associate-iam-instance-profile \
    --instance-id i-1234567890abcdef0 \
    --iam-instance-profile Name=MyS3ReadOnlyRole

アクセスキーをソースコードや設定ファイルに書くのは 重大なセキュリティリスク です。Git に push してしまい、不正利用されるという事故が後を絶ちません。EC2 や Lambda には必ず IAM ロールを使いましょう。

IAM のベストプラクティスまとめ

項目	やるべきこと
ルートユーザー	MFA を設定して日常使用しない
個別ユーザー	共有アカウントは作らず、1 人 1 ユーザー
グループ	ユーザーをグループにまとめてポリシーを付与
ロール	AWS サービスへの権限付与はロールで
最小権限	必要な権限だけを付与する
アクセスキー	コードに埋め込まない。ロールを使う
MFA	全ユーザーに MFA を有効化
定期棚卸し	使っていないユーザー・キーは削除する

3. セキュリティ管理

AWS のセキュリティサービス全体像

AWS にはセキュリティに関するサービスが多数あります。役割ごとに整理すると見通しがよくなります。

AWS WAF

WAF（Web Application Firewall）は、Web アプリケーションへの攻撃（SQL インジェクション、XSS など）を防ぐサービスです。CloudFront や ALB（Application Load Balancer）の前段に配置して使います。

AWS Shield

Shield は DDoS 攻撃（大量のアクセスでサービスをダウンさせる攻撃）からの保護サービスです。

プラン	料金	内容
Shield Standard	無料（自動で有効）	一般的な DDoS 攻撃からの保護
Shield Advanced	有料（月額 $3,000〜）	高度な攻撃検知、DDoS 専門チームの対応、コスト保護

検知系サービス — 異常を見つける

サービス	何をするか	たとえ話
GuardDuty	AI / 機械学習で脅威を自動検知（不審な API 呼び出し、マルウェア通信など）	防犯カメラの AI 解析
Inspector	EC2 や Lambda の脆弱性を自動スキャン	定期的な建物の安全点検
Config	リソースの設定変更を記録し、ルール違反を検知	「S3 が公開設定になったら通知」

# GuardDuty を有効化する（リージョンごとに実行）
aws guardduty create-detector --enable

GuardDuty は 有効化するだけ で脅威検知が始まるので、全リージョンで有効にしておくのがおすすめです。

記録系サービス — 証跡を残す

サービス	何を記録するか	用途
CloudTrail	API 呼び出しの履歴（誰が・いつ・何をしたか）	監査、不正操作の追跡
CloudWatch Logs	アプリケーションや OS のログ	障害調査、モニタリング
VPC フローログ	ネットワーク通信の記録（許可/拒否）	不正通信の検知

CloudTrail は 「いつ・誰が・何をしたか」を全部記録してくれる監視カメラ です。デフォルトで 90 日分の管理イベントが記録されますが、S3 に保存するように設定すれば長期間保管できます。

暗号化 — データを守る

場面	サービス/機能	説明
保存時の暗号化	KMS（Key Management Service）	暗号鍵の作成・管理。S3、RDS、EBS 等と連携
通信の暗号化	ACM（AWS Certificate Manager）	SSL/TLS 証明書の発行・管理（無料）
S3 の暗号化	SSE-S3 / SSE-KMS	バケット単位で暗号化を有効化

# S3 バケットにデフォルト暗号化を設定
aws s3api put-bucket-encryption \
    --bucket my-bucket \
    --server-side-encryption-configuration '{
        "Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]
    }'

コンプライアンス

サービス	何をするか
AWS Artifact	AWS のコンプライアンスレポート（SOC、ISO 等）をダウンロードできる
Amazon Macie	S3 に保存された個人情報（PII）を機械学習で自動検出

セキュリティのベストプラクティスまとめ

カテゴリ	やるべきこと
ネットワーク	セキュリティグループで必要なポートだけ開ける
検知	GuardDuty を全リージョンで有効化
記録	CloudTrail を有効にして S3 に長期保管
暗号化	S3・RDS・EBS は暗号化を有効にする
パッチ	EC2 の OS パッチを定期適用（Systems Manager 活用）
点検	Inspector で脆弱性を定期スキャン

まとめ

責任共有モデル

AWS は クラウド「の」セキュリティ、ユーザーは クラウド「内の」セキュリティ を担当
マネージドサービスを使うほどユーザーの責任は軽くなる

権限管理（IAM）

ルートユーザーは日常使用しない。MFA を設定してロック
最小権限の原則 で必要な権限だけ付与する
AWS サービスへの権限は IAM ロール で付与（アクセスキーをコードに埋め込まない）

セキュリティ管理

予防（セキュリティグループ、WAF）、検知（GuardDuty、Inspector）、記録（CloudTrail）、暗号化（KMS）の 4 層で守る
GuardDuty と CloudTrail は 有効化するだけ で効果があるので最優先

次のステップとしては、まず自分の AWS アカウントで「ルートユーザーに MFA を設定」「IAM ユーザーを作成」「CloudTrail と GuardDuty を有効化」の 3 つをやってみるのがおすすめです。この 3 つだけで、セキュリティレベルが大きく向上します。

参考文献

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up