チーム間のアクセス境界設計 — 権限と名前空間の分け方、誰がどの範囲を管理するか

チーム間のアクセス境界は、構成が小さいうちは感覚的な運用でも乗り切れる。しかし環境数が10を超え、チームが3つ以上に分かれた段階で、境界の曖昧さは事故と手戻りの直接的な原因に変わる。権限の分け方・名前空間の粒度・管理委任の範囲をあらかじめ構造として設計しておくことが、拡張可能なインフラ運用の前提条件です。

チーム間のアクセス境界が曖昧なまま拡大した構成で起きる問題の整理

「触れてしまう」構造が生む意図しない変更

複数チームが同一の名前空間やアカウントを共用している場合、操作対象の誤認が発生しやすい構造になっている。開発チームのメンバーが誤って本番の設定リソースを変更するというインシデントは、権限の分離がないフラットな構成では防ぎようがない。現場では「誰が何を変更したのかわからなくなった」という状況が、チームが2つから3つに増えた直後に頻発するという話をよく聞く。意図しない変更のリスクはチーム数の増加に比例して上がるため、アクセス境界の設計は規模が小さいうちに着手するほど整理コストが低く抑えられる。

共有サービスアカウントが引き起こす追跡不能

チーム間で同一のサービスアカウントやIAMユーザーを使い回している構成では、変更の実行者を事後に特定できない状況が生まれる。監査ログには「共有アカウント」の操作として記録されるため、障害発生時の原因特定に数時間から数日を要することがある。20台以上のノードを抱える本番環境でこの状況が発生すると、障害対応の工数が倍以上に膨らむケースが報告されている。共有アカウントは一見管理が楽に見えるが、トレーサビリティを捨てる設計選択であることを認識した上で判断する必要がある。

権限の肥大化と「なんでもできるアカウント」

小規模時は便利に見える管理者権限の共用が、チームが増えるにつれて「誰でも何でもできる」状態を固定化する。この状態で新メンバーがオンボードすると、最小権限の原則を後から適用しようとしても既存の依存関係が複雑に絡み、整理に数週間を要することがある。権限の肥大化は静かに進行するため、気づいたときには設計の全面的な見直しが必要になっているケースが多い。小さな例外の積み重ねが、後の大きな設計負債になる。

名前空間・プロジェクト・アカウントの分離粒度比較

分離の3レイヤーとその特性

アクセス境界の設計では、「名前空間（Namespace）」「プロジェクト/管理グループ」「アカウント/サブスクリプション」の3レイヤーを使い分けることが基本になる。名前空間はリソースのグループ化単位であり、同一プロジェクト内での論理的な分離に使われる。プロジェクト単位の分離は課金・権限・ネットワークの境界を兼ね、より強い独立性を提供する。アカウント分離はさらに強固な境界を提供するが、クロスアカウントのアクセス設計が必要になるため設計・運用コストも上がる。3レイヤーはどれかひとつに統一するより、チームの規模感に合わせて組み合わせて使う判断が現実的です。

分離レイヤー	境界の強さ	クロスアクセスの複雑さ	推奨する規模感
名前空間（Namespace）	低〜中	低（同一プロジェクト内）	チーム1〜2・環境5以下
プロジェクト/管理グループ	中〜高	中（クロスプロジェクトポリシーが必要）	チーム3〜5・環境6〜20
アカウント/サブスクリプション	高	高（クロスアカウントロール・VPC連携が必要）	チーム6以上・環境21以上

チーム規模別の推奨粒度

チームが5名以下・環境数が5つ以下であれば、名前空間の分離とRBACの組み合わせで十分なことが多い。一方、チームが3つ以上・環境数が15以上になる規模では、プロジェクト単位かアカウント単位の分離が現実的な選択になる。分離粒度の判断基準は「チームが独立してデプロイできるか」と「課金を独立して追跡できるか」の2点に集約される。この2点を満たさないまま規模を拡大すると、後から境界を引き直す作業が大きな設計負債になる。

過剰分離の落とし穴

分離を細かくしすぎると、クロス境界のアクセス設計の複雑さが運用コストを押し上げる。特に共有データベースや共通ログ基盤にアクセスする際、境界を越えるたびに認証フローが増え、デバッグが困難になる。分離の粒度は「チームの独立性」と「リソースの共有度」のバランスで決めるべきで、すべてを分離すれば安全になるわけではない。共有頻度が高いリソースを境界の外側に置く設計も、有効な選択肢のひとつです。

チームごとのIAMロール設計 — 管理委任と共有リソースの境界の決め方

オーナーロールの委任範囲を設計する

各チームに「自チーム環境のオーナー」ロールを委任する際、そのロールが操作できる範囲をあらかじめ明確に定義しておく必要がある。委任の範囲が曖昧なまま渡すと、チームが意図せず共有インフラのリソースを変更するリスクが生まれる。委任するロールには「ここまでは自律的に操作できる」「ここからは中央管理チームへの申請が必要」という境界を明示する設計が求められる。委任の境界は一度引いたら固定ではなく、チームの成熟度に応じて拡張できる構造にしておくと運用しやすい。

共有リソースへのアクセスは集約管理が基本

ネットワーク共通部分・セキュリティグループ・共有ストレージなど、複数チームが利用するリソースは、チーム横断の管理者ロールが一元的に管理する構成が望ましい。チームごとに個別の変更権限を渡す設計は、変更の影響が他チームに波及しやすく、追跡も困難になる。共有リソースへのアクセスは「読み取りは自律、変更は申請」という原則を設計段階で組み込み、例外を設けない運用ルールとして定着させる。この原則を後付けで導入しようとすると、既存の依存関係の洗い出しに相当な工数がかかる。

ロールの継承より明示的なアタッチを選ぶ

ロールの継承関係が複雑になると、実際にどの権限が有効なのかを追跡するのが困難になる。現場では「親ロールを変えたら想定外のチームの権限が変わった」という事例が散見される。継承を多用するより、チームごとに独立したロールを明示的にアタッチする設計のほうが、変更の影響範囲を把握しやすく、権限の棚卸しも容易になる。ロール設計のシンプルさは、長期的な運用コストに直結する設計の問題です。

読み取り専用と変更権限をどこで分けるか

変更権限を絞る判断軸

読み取り専用と変更権限の境界は、「障害時に誰が操作できる必要があるか」から逆算して決める方法が実用的です。障害対応のたびに申請が必要な設計は運用を阻害するため、緊急変更のパスをあらかじめ設計しておく必要がある。通常運用では読み取り専用とし、緊急時は一時的な権限昇格を許可する二段構えが、多くの現場で採用されている設計パターンです。昇格の手続きと期限を自動化しておくことで、手動での剥奪漏れを防ぐことができる。

ステージング・本番で権限を非対称にする

開発・ステージング環境での変更権限は広めに設定し、本番環境は変更権限を絞る非対称設計が現実的な選択です。ステージング環境で広い権限を持つメンバーが、そのまま同じ権限で本番を操作できる構成は誤操作のリスクを高める。本番への変更を「誰でも・いつでも」ではなく「誰が・何を・いつ・なぜ」という粒度で制御できる設計を最初から組み込んでおくことが、後からの事故防止に効く。環境間の権限の非対称さは、設計の原則として明文化しておく。

読み取り専用の「抜け穴」を設計段階で塞ぐ

読み取り専用ロールでも、機密情報を含むシークレットやトークンの値を取得できる設計は、実質的に境界として機能しない。シークレット管理のスコープを環境ごとに分離し、読み取り専用ロールからはシークレットの値を取得できない設計を初期から組み込む。この点は後から追加するより、名前空間設計の段階で組み込むほうが整合性を保ちやすく、設計の一貫性を確保できる。読み取り専用の「読み取れる範囲」を明示することが、境界設計の完成度を決める。

セルフサービスと申請承認をどこで切り替えるか

セルフサービス範囲の設計指標

すべての操作に申請フローを設けると、チームの自律性が下がり開発速度に影響する。セルフサービスに開放する操作の基準は「リバートが即座に可能か」と「影響範囲が自チームのみか」の2点で判断する。この2条件を満たす操作はセルフサービスに開放し、どちらかでも満たさない場合は申請フローを設けるという設計が、実運用で機能しやすい。基準を文書化しておくことで、新しい操作が追加されるたびに都度判断する手間を省ける。

申請承認が必要な操作の境界線

本番ネットワークポリシーの変更・セキュリティグループルールの追加・他チーム環境へのアクセス要求・IAMロールへの権限追加は、申請承認を必須とする代表的な操作群です。これらを事前に「申請必須リスト」としてドキュメント化しておくと、チームオンボード時の判断コストを大幅に削減できる。リストは定期的に見直し、運用実績を踏まえて更新する仕組みも設計のうちに含めておく。

承認フローの設計選択

承認フローはPull Request経由のコードレビューとして実装するか、専用のIAM管理ツールで実装するかを選択する場面が多い。コードレビュー型は変更履歴がGitに残り監査に強いが、緊急対応時の速度が落ちる。ツール型は速度は上がるが、承認記録が別システムに分散するリスクがある。どちらを選ぶかは「監査の厳密度」と「緊急対応の頻度」のバランスで決め、いずれの選択でも記録の残し方を統一しておくことが重要です。

監査のためにどのアクセスを記録すべきかの設計

記録対象の選択と優先度付け

すべての操作をログに残すと、ログの量が膨大になり実際の調査時に有用な情報が埋もれる。記録すべき操作の優先度は「本番環境への書き込み」「IAMロールの変更」「シークレットの取得」の3カテゴリを最上位に置き、次いで「クロス境界のアクセス」「権限昇格の操作」を記録対象とする設計が標準的です。ログの量を適切に絞ることで調査時の検索効率が上がり、アラート設計の精度も高まる。

ログの保存期間と利用目的の対応

セキュリティ監査目的のログは90日から180日の保存が一般的な基準とされているが、コンプライアンス要件がある場合は1年以上の保存を求められることもある。保存期間を設計段階で決めておかないと、後から変更する際にストレージコストと保存フォーマットの両方を見直す作業が発生する。利用目的（障害対応・セキュリティ監査・コンプライアンス）ごとに保存期間を分けて設計し、目的に応じた検索性を確保しておく。

アラート設計との連携

ログを記録するだけでなく、異常なアクセスパターンをリアルタイムで検知するアラート設計を組み合わせる。特に「通常時間外の本番操作」「短時間での大量の読み取り」「権限変更の連続実行」は、アラートのトリガーとして組み込む代表的なパターンです。アラートの設計はログ設計と同時に行うのが効率的で、後から追加すると検知ルールと実際のログフォーマットのずれが生じやすい。ログとアラートはセットで設計するという原則を最初から持っておく。

落とし穴 — 権限の借り越しと引き継ぎ漏れが起きやすいパターン

「とりあえず」の権限付与が積み重なる

緊急対応時に一時的に付与した広い権限が、対応完了後も剥奪されずに残るパターンは非常によく見られる。構築を任されたある担当者が本番環境の権限を一時昇格させたまま退職し、6ヶ月後の監査で発覚したという事例は珍しくない。権限の付与には必ず有効期限または剥奪タスクをセットで設計するという原則を、チームのプロセスとして定着させることが重要です。自動で期限切れになる一時権限の仕組みを最初から設計に組み込んでおくと、手動運用への依存を排除できる。

担当者交代時の引き継ぎ漏れ

チームの担当者が交代する際、前任者が保有していた個人的なアクセス権がそのまま残るケースが多い。特にサービスアカウントのキーを個人のローカル環境に保存していた場合、退職後もそのキーが有効なままになるリスクがある。引き継ぎ時のチェックリストに「アクセス権の棚卸し」を必須項目として組み込み、鍵やトークンのローテーションを手順として定義しておく。引き継ぎを個人の裁量に任せず、プロセスとして構造化することがリスク低減につながる。

「誰かが持っているはず」の権限の空白

権限設計が個人に紐づいている場合、担当者が不在になった瞬間に誰も操作できない「権限の空白」が発生することがある。特にオンコール対応中に権限不足で操作できないという状況は、障害対応時間を大幅に延ばす。権限をロール単位で設計し、特定の個人に依存しない構造にすることで、このリスクを回避できる。緊急時に「誰が操作できるか」を事前に設計しておくことが、境界設計の完成度を測る基準のひとつです。

以下のチェックリストを設計レビューの確認項目として活用できます。

• 名前空間・プロジェクト・アカウントの分離粒度をチーム数と環境数に基づいて決定しているか
• 共有リソースへの変更権限を中央管理チームに集約しているか
• 本番とステージングで変更権限を非対称に設計しているか
• 読み取り専用ロールからシークレットの値を取得できない設計になっているか
• セルフサービスと申請承認の切り替え基準が文書化されているか
• 緊急時の権限昇格に有効期限と自動剥奪の仕組みが組み込まれているか
• 本番環境への書き込み・IAMロールの変更・シークレット取得がログに記録されているか
• 担当者交代時のアクセス権棚卸しがプロセスとして定義されているか