ストーリー
田
田中VPoE
ガバナンスフレームワークが固まった。次は具体的なポリシーを設計する。ポリシーなき統制は属人的な判断になり、ポリシーだけあって実装がなければ絵に描いた餅だ
あなた
ポリシーの粒度が難しそうですね。細かすぎると開発の足かせになるし、粗すぎると意味がない
あ
田
田中VPoE
良い着眼点だ。ポリシーは「必須(Must)」「推奨(Should)」「任意(May)」の3段階で定義する。すべてを必須にすると身動きが取れなくなるし、すべてを任意にすると統制が効かない。バランスが鍵だ
ポリシー体系の設計
ポリシーの階層構造
クラウドポリシー体系:
Level 1: 基本方針(ポリシー)
├── クラウド利用基本方針
├── セキュリティ基本方針
└── コスト管理基本方針
Level 2: 標準(スタンダード)
├── アカウント管理標準
├── ネットワーク設計標準
├── データ管理標準
├── 暗号化標準
└── タグ付け標準
Level 3: 手順(プロシージャ)
├── アカウント申請手順
├── セキュリティレビュー手順
├── インシデント対応手順
└── コスト異常対応手順
| 階層 | 内容 | 承認者 | 適用範囲 |
|---|
| 基本方針 | 組織の方向性、原則 | CTO | 全社 |
| 標準 | 具体的な技術要件 | クラウド戦略統括 | 全クラウド利用者 |
| 手順 | 作業手順、テンプレート | CoE | 実務担当者 |
主要ポリシー領域
1. アカウント管理ポリシー
| ポリシー項目 | 強制レベル | 内容 |
|---|
| アカウント構造 | Must | マルチアカウント戦略に従った構造を使用すること |
| 命名規則 | Must | {環境}-{部門}-{用途}-{連番} の形式に従うこと |
| ルートアカウント | Must | MFAを有効化し、日常的に使用しないこと |
| IAMポリシー | Must | 最小権限の原則に従うこと |
| SSO | Should | 全アカウントにSSOを設定すること |
2. セキュリティポリシー
| ポリシー項目 | 強制レベル | 内容 |
|---|
| データ暗号化 | Must | 保存データ・通信データを暗号化すること |
| ネットワーク分離 | Must | 本番/ステージング/開発を分離すること |
| ログ取得 | Must | 全アカウントでCloudTrail/監査ログを有効化すること |
| 脆弱性スキャン | Should | 週次で自動スキャンを実施すること |
| ペネトレーションテスト | Should | 年次で外部テストを実施すること |
3. コスト管理ポリシー
| ポリシー項目 | 強制レベル | 内容 |
|---|
| タグ付け | Must | コスト配賦に必要なタグ(部門、プロジェクト、環境)を付与すること |
| 予算アラート | Must | 月間予算の80%/100%/120%でアラートを設定すること |
| 未使用リソース | Should | 30日以上未使用のリソースを月次で棚卸すること |
| RI/SP購入 | Must | 一定金額以上のコミットメント購入はFinOpsチームの承認を得ること |
4. アーキテクチャポリシー
| ポリシー項目 | 強制レベル | 内容 |
|---|
| IaC | Must | すべてのインフラをコードで管理すること |
| 冗長性 | Must | 本番環境はマルチAZ構成とすること |
| バックアップ | Must | 定期バックアップと復旧テストを実施すること |
| コンテナ利用 | Should | 新規ワークロードはコンテナ化を優先すること |
| サーバーレス | May | 適切なワークロードではサーバーレスを検討すること |
タグ付け戦略
必須タグ体系
タグはクラウドガバナンスの基盤です。正確なタグなしにはコスト配賦もセキュリティ管理も成り立ちません。
| タグキー | 必須/任意 | 値の例 | 用途 |
|---|
Environment | 必須 | prod, stg, dev, sandbox | 環境識別 |
Department | 必須 | engineering, marketing, sales | コスト配賦 |
Project | 必須 | project-alpha, iot-platform | プロジェクト別コスト管理 |
Owner | 必須 | team-infra@example.com | 責任者の特定 |
CostCenter | 必須 | CC-1001, CC-2005 | 会計システムとの連携 |
DataClassification | 必須 | public, internal, confidential | セキュリティ分類 |
Compliance | 任意 | pci-dss, hipaa, gdpr | コンプライアンス要件 |
AutoShutdown | 任意 | true/false | コスト最適化 |
タグコンプライアンスの自動化
タグコンプライアンスフロー:
リソース作成
↓
タグチェック(自動)
├── 必須タグあり → OK → リソース利用可能
└── 必須タグなし → NG →
├── 即時: 作成者に通知
├── 24h後: マネージャーに通知
├── 72h後: リソースにタグ「non-compliant」付与
└── 7日後: リソース停止(本番以外)
ポリシーの例外管理
例外申請プロセス
すべてのポリシーには例外が必要になる場合があります。
| 項目 | 内容 |
|---|
| 申請者 | プロジェクトリード以上 |
| 承認者 | CoEリード + セキュリティ(セキュリティ関連の場合) |
| 必要情報 | 例外の理由、影響範囲、代替策、期限 |
| 有効期限 | 最大6ヶ月(延長は再申請) |
| レビュー | 月次の例外レビューで妥当性を再評価 |
例外の分類
| カテゴリ | 例 | 承認難易度 |
|---|
| 技術的制約 | 特定サービスが対応リージョンにない | 低い |
| ビジネス要件 | 顧客要件でオンプレミスが必要 | 中程度 |
| コスト要因 | マネージドサービスよりセルフマネージドが安い | 中程度 |
| セキュリティ例外 | 暗号化要件の一時的緩和 | 高い(CISO承認必要) |
ポリシーのライフサイクル管理
| フェーズ | 活動 | 責任者 |
|---|
| 策定 | ポリシードラフト作成、ステークホルダーレビュー | CoE |
| 承認 | 正式承認、公開 | クラウド戦略統括/CTO |
| 周知 | 全社への展開、トレーニング | CoE |
| 実装 | ガードレールとしての技術実装 | クラウドエンジニア |
| 監視 | コンプライアンス状態の継続的モニタリング | CoE |
| 見直し | 四半期ごとの妥当性レビュー | CoE + ステークホルダー |
まとめ
| ポイント | 内容 |
|---|
| ポリシー階層 | 基本方針→標準→手順の3階層で体系的に設計 |
| 強制レベル | Must/Should/Mayの3段階でバランスを取る |
| タグ戦略 | コスト配賦とセキュリティの基盤となる必須タグを定義 |
| 例外管理 | 例外は認めるが、プロセスと期限を明確にする |
チェックリスト
次のステップへ
次は「ランディングゾーン設計」を学びます。ポリシーを技術的に実装するランディングゾーンの設計方法を身につけましょう。
推定読了時間: 30分