クラウドセキュリティ実装とは｜IAM・VPC設計の基本ガイド
※本記事にはプロモーションを含む場合があります。
- IAMは「最小権限原則」が土台で、ロールごとに権限を分離するのが基本とされています
- VPCはCIDR設計とサブネット分割（Public/Private/Management）で構成します
- セキュリティグループ（ステートフル）とネットワークACL（ステートレス）の2層防御が有効とされています
- 踏み台サーバー経由のアクセスとMFA必須化で不正アクセスリスクを大きく下げられるとされています
- VPCフローログの中央集約で異常検知までの時間を短縮できるとされています
IAMとは何か
クラウド環境の設計において、ネットワークやサーバーの構成より先に検討すべきなのがIAM（Identity and Access Management）です。IAMはユーザーやサービスがどのリソースにどこまでアクセスできるかを制御する仕組みで、後から追加しようとすると既存の権限設定と競合し、修正に数日〜数週間かかるケースがあるとされています。
設計の起点になるのが「最小権限原則」です。ユーザーやサービスアカウントに対して、業務上必要な操作だけを許可し、それ以外は原則すべて拒否する考え方を指します。AWS IAM・Azure RBAC・Google Cloud IAMのいずれも、この原則に沿ったポリシー設計を推奨する記述を公式ドキュメントに掲載しています。権限を絞り込むほど、誤操作や設定ミスによる影響範囲は小さくなります。権限を「フルアクセス」から役割別に分割しておくことで、インシデント発生時に影響が及ぶリソースの範囲を限定しやすくなります。
IAM設計を後回しにすると、後から数百単位のポリシーを棚卸しする作業が発生することもあり、初期段階での設計コストは小さく見えても、放置した場合の是正コストの方が大きくなりやすい領域です。
最小権限の実装法
最小権限原則を実際の権限設計に落とし込む際は、まずロール体系を4〜5種類程度に整理するところから始めます。代表的な区分は以下のとおりです。
- Adminロール：リソースの作成・削除・ポリシー変更まで許可
- Developerロール：アプリケーションリソースのデプロイ・管理のみ許可
- ReadOnlyロール：監査・ログ閲覧のみに限定
- ServiceRole：特定のマイクロサービス間通信のみ許可
各ロールには、業務に必要なAPI呼び出しだけを許可するポリシーを個別に紐づけます。ロール数が10を超えるあたりから管理コストが跳ね上がりやすいため、まずは4〜5ロールでの運用を目安にし、必要に応じて分割する進め方が扱いやすいとされています。
ロールベースアクセス制御（RBAC）を導入すると、権限の棚卸し作業を定型化しやすくなり、属人的な権限管理から脱却する効果が期待できます。管理コンソール上でロールとポリシーのマッピングを一覧化しておくと、監査時の確認作業も短縮できます。
サービス認証と一時トークン
長期間有効なアクセスキーを複数人・複数サービスで共有する運用は、漏洩時の被害範囲が広がりやすい構成です。サービス間の認証には、有効期限付きの一時トークンを使う方式への切り替えが推奨されています。
- AWS STS（Security Token Service）やGoogle Cloudのサービスアカウントキーを使い、短命なトークンを発行する
- トークンの有効期限を1時間以内に設定し、自動更新の仕組みを組み込む
- 人間のユーザーに対してはパスワードに加えMFA（TOTP・U2Fなど）を必須化する
- すべての認証試行・権限変更・リソースアクセスをログに記録する
- ログを週1回以上の頻度で確認し、異常なアクセスパターンがないか点検する
MFAを導入するだけで、パスワード漏洩時のアカウント乗っ取りリスクを大幅に下げられるとされています。一時トークンとMFAを組み合わせた運用は、初期設定に半日〜1日程度かかることが多いものの、その後の運用負荷はほぼ増えない点が利点です。
VPCとCIDR設計
VPC（Virtual Private Cloud）は、クラウド上に構築するプライベートネットワークで、ネットワークセグメンテーションの出発点になります。設計時にまず決めるのがCIDRブロックです。
社内ネットワークや他クラウドとの接続を想定し、CIDR範囲が重複しないよう選定します（例：10.0.0.0/16）。その上でVPC全体を複数のサブネットに分割し、用途別に管理します。
- Public Subnet：Internet Gatewayと接続し、Webサーバーなどを配置
- Private Subnet：インターネット非接続。データベースやバックエンドを配置
- Management Subnet：運用ツール・監視・ログ保存専用
さらに複数の可用性ゾーン（AZ）にまたがってサブネットを配置することで、1つのAZで障害が発生しても他のAZでサービスを継続できる構成にできます。複数AZにまたがる構成にしておくと、単一のAZ障害がサービス全体の停止に直結しにくくなるとされています。
SGとACLの違い
VPC内のトラフィック制御は、セキュリティグループとネットワークACL（Access Control List）の2層で行うのが基本です。両者の役割は近いようで異なるため、混同すると想定外の通信を許可してしまうことがあります。
| 項目 | セキュリティグループ | ネットワークACL |
|---|---|---|
| 制御レベル | インスタンス単位 | サブネット単位 |
| 状態管理 | ステートフル（戻り通信は自動許可） | ステートレス（往復とも個別に設定） |
| ルール方式 | 許可ルールのみ | 許可・拒否を番号順に評価 |
| 粒度 | 比較的粗い | プロトコル・ポート範囲まで細かく制御 |
ルール例としては、443番ポートを社内CIDR（10.0.0.0/16）からのみ許可、22番ポートは管理者IP（203.0.113.0/24）からのみ許可、アウトバウンドはHTTPS通信のみ許可、といった構成が挙げられます。「許可したトラフィックのみ通す」という発想で設計すると、想定外の通信を遮断しやすくなります。2層で防御することで、一方の設定漏れをもう一方が補う多層防御が実現します。
セグメント設計と踏み台サーバー
ネットワークセグメンテーションは、単純なネットワーク分割ではなく、機能や責任範囲ごとに境界を引き、それぞれに独立した制御ポイントを設けることを指します。代表的なセグメント構成は以下のとおりです。
| セグメント | CIDR例 | 用途 | セキュリティレベル |
|---|---|---|---|
| Web層 | 10.0.1.0/24 | 外部向けサーバー | 中程度 |
| アプリ層 | 10.0.2.0/24 | ビジネスロジック | 高 |
| DB層 | 10.0.3.0/24 | データベース | 最高 |
| 管理層 | 10.0.4.0/24 | 運用・監視 | 最高 |
各セグメント間の通信はセキュリティグループで明示的に許可し、デフォルトはすべて拒否する設計が基本とされています。プライベートサブネット内のサーバーにアクセスする際は、踏み台サーバー（Bastion Host）を経由する構成が一般的です。管理者PCからBastion（Public）経由でAppサーバー（Private）にSSH接続する流れになります。踏み台サーバーへのアクセスは管理者IPに限定し、MFAを必須化した上で、アクセスログを一元管理・定期監査する運用が推奨されています。
監視ログの活用法
VPCフローログは、ネットワークインターフェースを通過するトラフィック情報を記録する機能で、不正なトラフィックパターンの検出やトラブルシューティング、コンプライアンス監査への対応に活用できます。フローログをCloudWatch・S3・CloudTrailなど中央ログシステムへ送信し、分析可能な状態にしておく運用が基本です。
異常なアクティビティを検出した際に自動対応するルールも設定できます。疑わしい送信元のセキュリティグループルールを一時的に修正する、影響のあるホストを他リソースから隔離する、Slack・メール・PagerDutyなどでインシデント通知を飛ばす、といった対応が代表例です。自動化しておくことで、検知から初動対応までの時間を数分単位に短縮できるとされています。
以下のチェックリストを月1回以上の頻度で確認しておくと、設定の陳腐化を防ぎやすくなります。
- □ すべてのユーザー・サービスアカウントに最小権限が設定されているか
- □ 使用されていないIAMロール・ポリシーは削除済みか
- □ すべてのインスタンスがセキュリティグループで保護されているか
- □ VPCフローログが有効化され、中央ログシステムに送信されているか
- □ 管理者アカウントへのアクセスはMFAで保護されているか
- □ DB・APIなど重要リソースへのアクセス元は明示的に制限されているか
- □ ネットワーク設定の変更履歴はCloudTrail等で追跡可能か
よくある質問
Q. IAMの最小権限原則はどこから手をつければいいですか？
A. まず既存ユーザー・サービスアカウントの権限を棚卸しし、実際に使われているAPI呼び出しだけを許可する形に絞り込むところから始める進め方が扱いやすいとされています。ロール数は最初4〜5種類程度に抑えると管理しやすくなります。
Q. セキュリティグループとネットワークACLは両方設定する必要がありますか？
A. 制御レベル（インスタンス単位かサブネット単位か）と状態管理方式（ステートフルかステートレスか）が異なるため、両方を組み合わせた2層防御が推奨されています。片方だけでは設定漏れをカバーしきれないケースがあります。
Q. VPCのCIDRブロックはどう決めればいいですか？
A. 社内ネットワークや他のクラウド環境と重複しない範囲を選定します。10.0.0.0/16のような広めのレンジを確保し、サブネットごとに/24単位で分割する設計がよく使われています。
Q. 踏み台サーバーは必須ですか？
A. プライベートサブネット内のリソースに直接インターネットからアクセスできる状態は避けるべきとされており、踏み台サーバー経由でのアクセスとMFA必須化がセットで推奨されています。
Q. VPCフローログはどのくらいの頻度で確認すればいいですか？
A. 週1回程度の定期確認に加えて、自動対応ルールで異常検知時に即時通知が飛ぶ体制を組み合わせる運用が扱いやすいとされています。手動確認だけに頼ると、異常の発見が数日遅れることもあります。
Q. NIST・CIS BenchmarksなどのフレームワークはIAM/VPC設計にどう関係しますか？
A. NIST Cybersecurity FrameworkやCIS Benchmarksは、IAM・VPC設計の妥当性を第三者的に確認するためのチェックポイント集として使われることが多く、社内基準を作る際のたたき台として参照されています。
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
