ページ内に広告が含まれる場合がございます。
クラウドの世界では、リソースの管理とセキュリティを切り離して考えることはできません。
特に重要なのが「IAM(Identity and Access Management)」、つまり誰が・何に・どこまでアクセスできるかを管理する仕組みです。
今回は、AWS・GCP・AzureそれぞれのIAMの構成、考え方、実務でのポイントを比較・解説します。
IAMとは?
IAM(Identity and Access Management)は、クラウド環境における「認証(Authentication)」と「認可(Authorization)」を一元的に管理する仕組みです。
IAMでできること
- ユーザーやグループの作成と管理
- ロールやポリシーを使ったアクセス制御
- 多要素認証(MFA)の強制
- サービスアカウントの制御(システム用)
IAMの基本構成と用語比較
要素 | AWS | GCP | Azure |
---|---|---|---|
ユーザー | IAM User | Cloud Identity User / IAM User | Azure AD User |
グループ | IAM Group | Google Group | Azure AD Group |
ロール | IAM Role | IAM Role | Role Assignment |
ポリシー | IAM Policy(JSON) | 役割ベースIAM | RBAC(Role-Based Access Control) |
組織階層 | Organization > Account > Resource | Organization > Folder > Project > Resource | Tenant > Subscription > Resource Group > Resource |
IAMの構造と階層的なアクセス制御
- AWS
-
- IAMユーザー/グループ/ロール/ポリシー
- ユーザーに直接ポリシーを付けたり、ロールにアタッチして委任可能
- S3、EC2などのリソースごとに細かい制御が可能
- GCP
-
- ロールベースIAM
- 各レベル(Organization / Folder / Project / Resource)でアクセス制御
- サービスアカウントが重要(VMなどがAPI操作するため)
- Azure
-
- RBACモデル(Role-Based Access Control)
- リソースグループ単位での制御が中心
- Azure ADと密接に連携
IAMの代表的なユースケース
ユースケース | 説明 | 各クラウドでの設定例 |
---|---|---|
開発者にS3だけ読み取り権限を付与 | 最小権限の原則に沿った制御 | AWS:ReadOnlyAccessポリシー / GCP:Viewer / Azure:Reader |
自動バックアップツールからのAPI実行 | サービスアカウントによる認可 | IAMロール or サービスアカウントをアタッチ |
一時的な権限付与(期限付き) | オペレーション時のみに制御 | AWS:AssumeRole + duration / GCP:一時的なバインディング / Azure:PIM(Privileged Identity Management) |
各クラウドにおけるIAMポリシーの記述例
AWS(JSONベース)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}
GCP(バインディング)
bindings:
- role: roles/storage.objectViewer
members:
- user:example@example.com
Azure(ロール割り当て)
Azureでは個別ポリシーを書くというより、定義済みロールを対象に割り当てる形式が中心。
セキュリティ強化のベストプラクティス
ベストプラクティス | 内容 |
---|---|
最小権限の原則 | 必要なリソースに、必要な範囲・時間だけ |
MFAの有効化 | すべてのユーザーに対して多要素認証を推奨 |
サービスアカウント鍵のローテーション | 長期間同じ鍵を使わない(GCP/Azure) |
アクティビティログの監査 | AWS CloudTrail、GCP Audit Logs、Azure Monitorでの操作ログ確認 |
管理者権限の集中管理 | 無制限ロールのばら撒きを避け、統制ポイントを明確にする |
実務でよくあるIAMの落とし穴
- ポリシーの適用範囲を誤って広げてしまい、他部署のリソースまで見えてしまう
- デフォルトの「Owner」「Editor」ロールをそのまま使って事故
- サービスアカウントに強すぎる権限を付けて意図せず外部通信
おわりに:IAMはクラウドセキュリティの要
IAMは地味に見えて、クラウド運用の最重要ポイントです。
セキュリティ設計、業務効率、トラブル対応すべてに直結します。
インフラエンジニアやプリセールスとしては「ロールベース設計+最小権限+監査ログ」がキーワードになります。
次回は「サーバレス(FaaS)」をテーマに、各クラウドにおける違いや代表的な活用方法を紹介していきます。