情シス向け：クラウドガバナンスを作る方法（アカウント/権限/ポリシー設計）

クラウドガバナンスとは？「自由に使える」と「事故を防ぐ」を両立する仕組み

クラウドは、サーバーやサービスを短時間で用意できる一方で、使い方を決めないまま拡大すると「誰が何を作ったのか分からない」「権限が強すぎる」「請求が急に増えた」「情報漏えいが怖い」といった問題が起きやすくなります。ここで必要になるのがクラウドガバナンスです。クラウドガバナンスとは、クラウド利用におけるアカウント・権限・ルール（ポリシー）・監査・コスト管理を、会社として継続運用できる形に整えることです。

情シスの現場では「セキュリティを厳しくしすぎると現場が止まる」「緩すぎると事故が起きる」という板挟みになりがちです。ガバナンスの目的は、単に制限することではありません。最終的には、(1)必要な人が必要な範囲で使える、(2)万一のときに原因追跡と復旧ができる、(3)予算内で継続的に改善できる、という状態を作ることです。

本記事では、開発に詳しくない情シスの方でも進められるように、クラウドガバナンスを「アカウント設計」「権限設計」「ポリシー設計」「運用（監査・コスト・変更管理）」に分解して、手順と実務の落とし穴まで解説します。AWS・Azure・Google Cloudなど個別製品に依存しない考え方を中心にしつつ、各クラウドで共通する実装ポイント（組織/プロジェクト、IAM、ログ、タグ、ポリシー）も押さえます。

最初に決めるべき前提：対象範囲・責任分界・ゴールを「紙1枚」にする

クラウドガバナンスを作る際、いきなり権限やルールの細部に入ると高確率で迷子になります。まずは「何を守り、誰が運用し、どこまで管理するか」を、社内合意できる粒度で定義しましょう。ポイントは技術ではなく、業務と責任の線引きです。

対象範囲（スコープ）を決める

「全社のクラウド全部」を一気に整備しようとすると、意思決定が重くなり、現場に反発され、結局進みません。おすすめは、影響が大きい順に段階的にスコープを切ることです。例えば、(1)本番環境と個人情報を扱うシステム、(2)全社共通基盤（ID、ネットワーク、ログ）、(3)検証・開発環境、の順に整えます。

責任分界（RACI）を明確にする

クラウドは「クラウド事業者が守る部分」と「利用者が守る部分」が分かれます。さらに社内でも、情シス・開発・各事業部・外部ベンダーの責任を曖昧にすると事故対応が遅れます。最低限、次の項目は担当を決めましょう。

• ID管理（誰がアカウントを作り、削除し、権限を見直すか）
• ネットワーク/セキュリティ設定（誰が標準を作り、例外を承認するか）
• ログ・監査（何を保存し、誰が見るか）
• コスト（予算枠、アラート、部門按分のルール）
• 変更管理（本番変更の申請、レビュー、緊急対応）

ゴールを「測れる形」にする

ガバナンスは運用がすべてです。「ちゃんとしている」ではなく、測れるゴールにします。例としては、(a)管理者権限の付与は申請制で24時間以内に処理、(b)本番環境の操作ログを1年以上保存、(c)未使用リソースを月1で棚卸し、(d)請求が前月比20%増でアラート、などです。こうした指標があると、経営層への説明もしやすくなります。

アカウント設計：まず「分ける」。全社で迷わない入れ物を作る

クラウドガバナンスの土台はアカウント設計です（クラウドによっては「サブスクリプション」「プロジェクト」「テナント配下の管理単位」など呼び方が異なります）。ここでの狙いは、事故時の被害を小さくし、請求や権限を整理し、監査に耐える構造にすることです。難しい技術よりも、業務単位とリスク単位で分けることが重要です。

基本の分け方：本番・検証・共通基盤を分離

最低限、次の3つは分けるのが定石です。

• 本番（Production）：顧客影響がある。権限は厳しめ。変更管理と監査が必須。
• 検証/開発（Non-Production）：スピード重視。コスト上限や自動停止など、費用ガードを強める。
• 共通基盤（Shared/Platform）：ID連携、ログ集約、ネットワーク、セキュリティ監視などを集約。

この分離だけでも、誤操作で本番設定を壊すリスク、ログが散らばる問題、請求の見えにくさが大幅に改善します。特に共通基盤は「全社の監査と可視化の中心」なので、最優先で整える価値があります。

組織構造：部門別か、システム別か

よくある悩みが「アカウントを部門ごとに分けるべきか、システムごとに分けるべきか」です。結論は、監査と予算の単位に合わせます。

• 部門別が向く：部門ごとに予算管理が明確で、システムも部門内に閉じる
• システム別が向く：複数部門が使う基幹/共通システムが多い、外部委託が多い

中小企業では、最初は「本番」「検証」「共通」の3分割で十分なことも多いです。大企業でも、初期は重要システムから先に分け、段階的に増やす方が現実的です。

アカウント命名・タグ（ラベル）で「後から困らない」状態にする

クラウドは資産が増えやすく、名称がバラバラだと棚卸し不能になります。命名規則はシンプルで構いませんが、必ずルール化しましょう。また、クラウドのタグ（ラベル）機能は、コスト按分や管理の要です。最低限、次のタグを必須にすると運用が楽になります。

• Owner（責任者/窓口）
• System（システム名）
• Env（prod/dev/stgなど）
• CostCenter（部門/予算コード）
• Retention（期限・廃止予定）

権限設計（IAM）：最小権限・ロール分離・特権IDの扱いが勝負

クラウドの事故原因で特に多いのが「権限が強すぎる」「共有IDで誰がやったか分からない」です。権限設計（IAM）は細かく感じますが、考え方をパターン化すれば難易度は下がります。重要なのは個人単位の認証＋役割（ロール）で権限を付け替える設計です。

原則：個人アカウント＋SSO（シングルサインオン）

まず、共有アカウントは原則禁止にします。退職・異動時に止められない、パスワードの使い回しが起きる、監査で説明できない、という問題がセットで発生するためです。理想は、社内のID基盤（Microsoft Entra ID/Google Workspace等）とクラウドをSSO連携し、入退社の手続きと権限を連動させます。

SSOが難しい場合でも、クラウド側で個人アカウントを作り、MFA（多要素認証）を必須化するだけで、リスクは大きく下がります。MFAは「パスワードが漏れても、もう一段の確認が必要」になる仕組みです。

ロール設計：人に権限を直付けしない

運用が破綻しやすいのが「Aさんにこの権限、Bさんにあの権限」と個別付与する方式です。異動やプロジェクト変更で増減が追えず、いつの間にか権限が積み上がります。対策は、代表的なロールを先に定義し、ユーザーはロールに所属させる方法です。

• 閲覧（ReadOnly）：監視・確認・監査向け。原則これを標準にする。
• 運用（Operator）：再起動やスケールなど定型作業のみ。
• 開発（Developer）：検証環境での作成・変更。範囲は非本番に限定。
• 管理（Admin）：原則は最小人数。日常利用しない。

クラウドでは「どのアカウント/プロジェクトに対して」「どの操作を許可するか」を組み合わせられます。例えば、開発者は開発環境のみ作成OK、本番は閲覧のみ、といった形にします。

特権（管理者）権限：常時付与しない、使ったら記録する

管理者権限は、便利ですが事故の爆心地にもなります。情シスが実務で採用しやすいのは、次の3点セットです。

• 常時Adminを持つ人を最小化：通常は閲覧/運用ロールで仕事をする
• 昇格（Just-in-Time）：申請・承認で一定時間だけAdminにする
• 特権操作のログを別保管：削除されない場所に集約する

「JITは難しそう」と感じる場合でも、まずは「管理者用の別アカウントを作り、普段使い禁止」「本番作業はチケット番号がないと実施不可」など、運用ルールから始められます。

外部ベンダーのアクセス：契約より先に技術で制御する

委託先にクラウド作業を依頼する場合、口約束や契約条文だけでは防げないミスが起きます。クラウドガバナンスとしては、(1)作業用ロールを用意し、範囲と期限を限定、(2)操作ログを必ず取得、(3)接続元IPや時間帯を制限できるなら設定、が現実的です。特に期限を設けないと、プロジェクト終了後もアクセスが残り続けます。

ポリシー設計：守るべきルールを「自動で守らせる」仕組みにする

ガバナンスはルールを作って終わりではなく、守られる状態にすることが本質です。人の注意力に依存すると、忙しいほど形骸化します。そこで、クラウドのポリシー機能（組織ポリシー、SCP、Azure Policy等）を使い、危険な設定をそもそも作れない・気づけるようにします。

まずは「禁止」より「標準化」と「検知」から

いきなり強い禁止ルールを入れると、現場が動かなくなり、例外だらけになります。おすすめの進め方は、(1)標準テンプレートを用意、(2)逸脱を検知して通知、(3)重要領域のみ禁止、の順です。例えば、ストレージの公開設定や、ログ無効化、暗号化なし、といった重大項目から着手します。

最低限そろえたいポリシー（実務で効くもの）

• 公開範囲：インターネット公開は原則禁止、例外は申請制
• 暗号化：保存データは暗号化を必須（鍵管理の責任者も定義）
• ログ：監査ログの停止・削除を禁止、保存期間を規定
• リージョン制限：データ所在要件がある場合は利用地域を限定
• タグ必須：Owner/Env/CostCenterなどがないリソース作成をブロック
• 外部共有：共有リンクや公開設定の自動検知・是正

特に「ログ停止の禁止」「タグ必須」「公開の検知」は、クラウドの運用負荷を大きく下げます。情シスが少人数でも回せる仕組みになります。

テンプレート化（IaC/構成標準）：情シスが“審査”から“提供”へ

現場のスピードと安全性を両立する鍵がテンプレートです。ネットワーク、監視、バックアップ、標準のセキュリティ設定をセットにした雛形（テンプレート）を用意し、「これを使えば安全に作れる」状態にします。コードでの自動化（Infrastructure as Code）が理想ですが、最初から高度にしなくても、チェックリスト付きの標準構成、承認済み構成図、設定例の提供でも十分効果があります。

運用設計：ログ監査・変更管理・コスト管理を“仕組み化”する

クラウドガバナンスは、運用で差が出ます。導入時は整って見えても、半年後に権限が増殖し、ログが見られず、費用が膨らみ、結局「よく分からない状態」に戻ることが多いからです。ここでは、情シスが現実的に回せる運用の型を紹介します。ポイントは定期作業を減らし、アラートで気づけるようにすることです。

ログと監査：まず「集約」と「改ざん耐性」

ログは、問題が起きたときに初めて価値が分かります。だからこそ、(1)各アカウント/プロジェクトのログを共通基盤へ集約、(2)管理者でも簡単に消せない保存先に保管、(3)誰が何をしたか（認証・権限変更・設定変更）を追える、という3点が重要です。保存期間は法令や社内規程に合わせつつ、少なくとも数か月〜1年を目安に検討します。

変更管理：本番は「手順化＋承認＋ロールバック」

本番環境の変更で必要なのは、厳しさより再現性です。最低限、(a)変更申請（目的/影響/手順/戻し手順）、(b)承認者（システムオーナー＋情シス）、(c)実施ログ（いつ誰が何をしたか）、を揃えます。クラウドでは設定変更が多岐にわたるため、チェックリストを共通化すると回しやすくなります。

• 本番の管理者操作は「作業用アカウント」で実施し、普段の業務アカウントと分ける
• 緊急対応（障害時）のルートを別に用意し、後で必ず振り返りをする
• 設定の差分が追える仕組み（構成管理、変更履歴）を整える

コスト管理（FinOpsの入口）：予算化・見える化・止める仕組み

クラウドのコストは「使った分だけ」なので、ガバナンスなしだと増えやすいです。情シスが取り組みやすい順に並べると、(1)アラート、(2)タグで按分、(3)無駄の削減、(4)予約/割引の最適化、です。まずは「今月いくらか」を翌月に知るのではなく、週次または日次で増加に気づく仕組みを作ります。

権限レビュー：月1回の“棚卸し”を儀式にしない

権限の見直しは形骸化しやすい作業です。おすすめは、(1)管理者権限と外部ベンダー権限だけは毎月、(2)その他は四半期、のように優先順位を付けることです。また「利用実績がない強い権限」を自動で洗い出せるなら、対象者に確認して外していく運用が現実的です。

失敗しない進め方：小さく始めて、例外を管理し、全社展開する

クラウドガバナンスは、完成形を一度に作るより、運用しながら改善する方が成功します。特に、開発に詳しくない情シスが主導する場合、最初から完璧を目指すと「現場が使えない」「設定が複雑で維持できない」になりがちです。ここでは、現実的なロードマップを提示します。

フェーズ分けの例（3か月〜）

• フェーズ1：個人アカウント化、MFA必須、ログの集約、本番/検証/共通の分離
• フェーズ2：ロール設計、管理者権限の最小化、タグ必須、コストアラート
• フェーズ3：ポリシーで重大設定を禁止、テンプレート提供、JIT昇格、監査レポート

この順番は、効果が出やすく、かつ現場の反発が少ない並びです。「止める」より「見える化」「土台作り」を先に置くのがポイントです。

よくある落とし穴と回避策

• 落とし穴：ルールが多すぎて読まれない → 回避：重大ルールは10個以内、詳細は別紙/FAQに分離
• 落とし穴：例外だらけで形骸化 → 回避：例外は期限付き、棚卸しで自動的に戻す
• 落とし穴：担当者がいないと回らない → 回避：承認フロー、テンプレ、アラートで属人性を下げる
• 落とし穴：ベンダー依存でブラックボックス → 回避：設計書・権限表・ポリシー一覧・運用手順を成果物化

経営・監査への説明は「リスクと言語化」で通す

経営層にクラウドガバナンスを説明する際、技術の話より「会社として避けたい損失」を言語化する方が伝わります。例えば、情報漏えい（信用毀損・賠償）、サービス停止（売上機会損失）、不正利用（請求増）、監査指摘（改善コスト）です。ガバナンス施策はそれらを下げる投資だと整理できます。

また、情シスのKPIとして「ログ取得率」「管理者権限の人数」「タグ付与率」「未使用リソース削減額」などを提示すると、継続予算も取りやすくなります。

まとめ

クラウドは導入が簡単な分、放置すると権限・設定・コストが増え、事故に直結します。情シスが主導するクラウドガバナンスは、難しい技術を完璧にすることではなく、アカウントを分け、権限を最小化し、ポリシーで自動化し、ログとコストを継続運用することが要点です。

• 最初に「対象範囲・責任分界・ゴール」を紙1枚で合意する
• アカウント（プロジェクト/サブスク）を本番・検証・共通基盤で分離する
• 権限は個人アカウント＋ロールで管理し、管理者権限は常時付与しない
• ポリシーで危険設定を防ぎ、タグ必須・ログ停止禁止など“効く”ところから固める
• ログ集約・変更管理・コストアラートを仕組み化し、段階的に全社展開する

「どこまで厳しくすべきか」「既存環境がすでに散らかっている」「ベンダー運用から内製に寄せたい」など、状況によって最適解は変わります。重要なのは、現場の速度を落とさずに、事故と無駄を減らす設計にすることです。