Access Approval

解決する課題

クラウドを使う以上、障害対応やサポート対応の過程で クラウド事業者側の担当者が自社のデータやリソースに触れる場面が避けられません。金融・医療・公共などの規制業種では「事業者の人がいつ何の目的で自社データに触れたのか」を把握し、できれば事前に許可した時だけ触れさせたいという要件が生じます。Access Approval は、この「事業者側アクセスの事前承認」を顧客側でコントロールできるようにします。

• Google のサポートや SRE が自社データにアクセスする前に、気づかないまま触れられるのを避けたい → アクセス前に承認を求めさせたい
• 規制対応の監査で「事業者アクセスを顧客が統制している」ことを示したい → 承認/拒否の証跡を残したい
• どの担当者がどんな理由でアクセスを求めたかを把握したい → 誰が・いつ・なぜを可視化したい

主要概念と用語

• Access Approval（アクセス承認）: Google 側の担当者が顧客リソースへアクセスする前に承認リクエストを発行させ、顧客が許可または拒否できる機能。許可されるまでアクセスをブロックする関門として働く
• Access Transparency（アクセストランスペアレンシー）: Google 側のアクセスを 事後のログとして記録・可視化する機能。Access Approval を有効化する前提となる土台
• 承認リクエスト（Approval Request）: アクセスの理由（サポートケース番号など）・対象リソース・要求した担当者の所属地域などを含む、承認を求める単位
• 承認/拒否（Approve / Dismiss）: 顧客が承認リクエストに対して下す判断。承認しない限りアクセスは進まない（一部の緊急ケースを除く）
• 承認の署名鍵（Cloud KMS による署名）: 承認の正当性を暗号的に検証するため、顧客管理の鍵で承認に署名できる仕組み。なりすましや改ざんを防ぐ
• 除外理由 / 緊急アクセス: 障害復旧などサービス維持に不可欠な一部の操作は、承認なしに行われ得る。これらは Access Transparency のログ側に記録される
• 登録範囲（サービス単位の有効化）: Access Approval は対応するプロダクト単位で有効化し、すべての Google Cloud サービスが対応しているわけではない

仕様・制限・クォータ

• Access Approval を使うには、前提として Access Transparency が有効であること、および対象組織が対応する サポート/サブスクリプション要件を満たすことが必要。エディションや契約条件は変わり得るため公式の最新要件を確認する
• 承認は 対応プロダクト単位で機能する。すべてのサービス・すべてのアクセス経路を網羅するわけではなく、緊急時のサービス維持に不可欠な操作などは承認なしに行われ得る点に注意する
• 承認リクエストには有効期限があり、放置すると失効する。承認しないまま期限切れになるとアクセスは進まない
• 承認の管理は組織レベルで設定し、通知の宛先（Pub/Sub やメール）や承認操作には相応の IAM 権限が必要になる
• 個々のリクエストの粒度・通知のタイミング・対応プロダクト一覧は更新されるため、具体的な対応範囲は公式ドキュメントで都度確認する

内部の仕組み

Access Approval は、Access Transparency の上に「事前承認の関門」を重ねる構造です。

1. Google 側の担当者が、サポートケース対応などで顧客リソースへのアクセスを必要とする
2. その担当者のアクセスは即時には許可されず、承認リクエストが生成される。リクエストには理由・対象・担当者の所属地域などのメタデータが含まれる
3. 顧客は通知（Pub/Sub やメール、コンソール）でリクエストを受け取り、内容を確認して承認または拒否する
4. 承認された場合のみ担当者のアクセスが進む。顧客が Cloud KMS の鍵で署名する設定なら、承認が改ざんされていないことを暗号的に検証できる
5. 一連のアクセス自体は Access Transparency のログとして記録され、承認の有無・理由とあわせて事後監査ができる

設計パターン / ベストプラクティス

• まず Access Transparency から: いきなり承認制を敷くより、先に Transparency でアクセス実態を観測し、頻度や理由の傾向を把握してから Approval を導入する
• 通知を確実に届ける: 承認リクエストを Pub/Sub で受け、チケット/チャットへ連携して見落とさない経路を作る。期限切れによる対応遅延を防ぐ
• 承認フローを明文化: 誰が承認権限を持ち、どの基準（サポートケースの妥当性など）で承認/拒否するかを運用手順として決めておく
• 署名鍵で正当性を担保: 規制対応が厳しい場合は Cloud KMS の鍵で承認に署名し、承認の真正性を検証可能にする
• 対応範囲を棚卸し: 自社が使う主要サービスが Access Approval に対応しているかを確認し、対応外の経路は Transparency ログで補完して監視する

運用・監視

• 承認リクエストの到達と滞留を監視する。未対応のまま期限切れになるとサポート対応が滞るため、SLA を決めて担当を割り当てる
• 承認/拒否の操作自体は Cloud Audit Logs に記録される。誰がどのリクエストを承認したかを定期的にレビューする
• Access Transparency のログを SIEM（Chronicle など）へ取り込み、事業者アクセスの傾向や異常を継続的に分析する
• 承認の通知経路（Pub/Sub サブスクリプションやメール宛先）が生きているかを定期点検し、通知欠落で承認が止まらないようにする

コスト

Access Transparency や Access Approval の利用そのものに対する課金よりも、利用できる前提となるサポートやエディションの契約条件が実質的なコスト要因になります。対象になるには相応のサポートプランやサブスクリプションが必要な場合があり、承認通知に使う Pub/Sub や監査ログの取り込み先（ログ保管・SIEM）には各サービスの通常料金がかかります。料金区分・前提条件は変わり得るため、正確な条件は公式の料金・要件ページで確認してください。

セキュリティ

• 事業者側アクセスの最小化と可視化: 承認の関門により、Google 側アクセスを「気づかないまま」起きない状態に近づけ、理由とともに記録する
• 承認の真正性: Cloud KMS の鍵で承認に署名し、承認が本物であること・改ざんされていないことを検証可能にする
• 職務分離: 承認権限を持つロールを限定し、リソースの利用者と承認者を分けて相互牽制を効かせる
• 網羅性の前提を理解: 緊急時のサービス維持操作など承認を経ない経路がある点を踏まえ、Transparency ログ側の監視で補完する

関連サービス・比較

Access Approval は、事後ログの Access Transparency とセットで理解するのが要点です。Transparency は「Google 側が触れた事実」を後から可視化する窓であり、Approval はその手前に「触れる前に許可を求める扉」を追加します。Transparency が前提（土台）、Approval が能動的な統制（関門）という関係です。

ハンズオン / CLI例

# 1) Access Approval の設定（組織レベル）を確認する
gcloud access-approval settings get \
  --organization=ORGANIZATION_ID

# 2) 承認通知の宛先などを設定して有効化する
#    notification-emails に承認担当の宛先を指定する例
gcloud access-approval settings update \
  --organization=ORGANIZATION_ID \
  --notification-emails="approver@example.com"

# 3) 届いている承認リクエストの一覧を確認する
gcloud access-approval requests list \
  --organization=ORGANIZATION_ID \
  --state=PENDING

# 4) 内容を確認したうえで、特定のリクエストを承認する
gcloud access-approval requests approve REQUEST_NAME

# 5) 妥当でないと判断した場合は拒否する
gcloud access-approval requests dismiss REQUEST_NAME