高権限管理とは
- 高権限、特権ID、リリース権限、etc…
- 平常時は運用に必要な最低限の権限のみを持ち、リリース作業や障害対応などの必要なタイミングでのみ権限を一時的に付与する
- 安全な運用の面ではもちろん、上場すると J-SOX(内部統制) 法の面で証跡が必要だったり、金融系だと PCI DSS で必要だったりする
Google Cloud における一時付与方法
IAM Condition による時間制限付きでのポリシー更新
Overview of IAM Conditions | Cloud IAM Documentation | Google Cloud
条件付き IAM ポリシーで、ある時刻以降は権限を無効にする。
{
"bindings": [
{
"condition": {
"expression": "request.time < timestamp(\"2022-01-05T03:48:32.000Z\")",
"title": "limited"
},
"members": [
"user:sample@example.com"
],
"role": "roles/storage.admin"
},
〜省略〜
],
"etag": "***",
"version": 3
}
- これによって剥奪の考慮が必要ない
- 権限が無効になるだけでポリシーは残り続けるのでクリーニングしないとポリシーが汚くなる
- 基本ロールに condition は設定できない
高権限が付与された Group に追加する
REST Resource: members | Directory API | Google Developers
Workspace の Group を用意しておき、作業時にメンバー追加→終了時に削除する。
- 剥奪の実装が必要(剥奪タイミングの管理、失敗時のリトライ)
- 管理者が異なる場合都度 Workspace 管理者に依頼してグループを作る必要がある
時限つきトークンで Service Account として実行
Creating short-lived service account credentials | Cloud IAM Documentation | Google Cloud
トークンを利用して Service Account の権限で処理を実行する。
- アプリのみが触るリソースなどを Service Account 経由で触ったりする場合に使う(?)
- AWS の Assume Role に近い挙動が可能
- Service Account で実行になるので事前定義ロールの組み合わせをまとめることができる
- Service Account に対しての権限管理ができるので一時的に使用できる権限を厳密に管理できる
- 直接ユーザへ権限がつくわけではないので web コンソール作業はNG
事例
Google Cloud については IAM Condition を使っているケースが多かった
Spotify / メルペイ
- https://github.com/spotify/gimme
- https://engineering.mercari.com/blog/entry/sre-qray/
- IAM Condition を利用したパターン、申請、承認、権限付与を行う Web アプリケーション
マネーフォワード
- https://tech.mfkessai.co.jp/2021/07/granter/
- 「承認は事前にしておけば良いのでログだけ残るようにしよう」という思想なので付与の部分のみ
- GitHub Actions のみで動いているのでサーバー代もなし
- Workflow が自分で audit log を吐き出して BigQuery で証跡管理をしているらしい
他の public cloud のパターン
AWS
- ワークフローが作れる
- 特定ロールへの Assume Role 権限を付与
- https://dev.classmethod.jp/articles/workflow-to-add-temporary-privilege-by-ssm-automation/
Azure
- ワークフローが用意されている
- https://docs.microsoft.com/ja-jp/azure/active-directory/privileged-identity-management/pim-configure
今回の成果物
当初は Group 利用を検討 → IAM Condition を利用
選定理由
- 事例が多かった
- 客先展開も考えると Workspace はできれば触らないほうが楽なはず
- 管理対象が一番少ない
・Condition: ロール単品
・Group: ロール + グループ
・Service Account 権限: ロール + Service Account
ポイント
- 管理コストを下げるために DB を持たない
今回のケースは厳密なステータス管理が不要であったため、承認用のURLに有効期限を付けた - 証跡管理ができる(ログに吐き出す)
申請の流れ
- IAP 経由でアプリへログイン
- 申請内容を記入して登録
- 承認者へ Slack 通知(承認用 URL を通知)
承認の流れ
- IAP 経由でアプリへログイン
→ config で登録済の承認者アドレスだった場合かつ承認用 URL の有効期限以内であった場合にアクセス許可 - 承認した場合に IAM ポリシーを更新
- 承認 or 拒否の結果を申請者へ Slack 通知
お掃除
- 定期的に Cloud Scheduler が削除 API をキック(IAP 経由ではアクセス不可)
- 期限が切れているポリシーを取り除いて IAM ポリシーを更新