特権セグメンテーション
1）なぜセグメンテーションが必要なのか
特権セグメンテーションは「、ブラスト半径」エラーとインサイダーの乱用を減らすために重要です。オペレーションのスピードと規制要件の遵守を維持しながら、どのようなデータとどこでどのようなアクションを実行できるかを正確に制限できます。
賞金：- 「余分な権利」による事件の数が少なくなります。
- 迅速な調査：アクセスは透明で明示的です。
- SoD/コンプライアンス、実証可能な監査の遵守；
- 生産の中心への危険のない安全な実験そして速い解放。
2）原則
Zero Trust：各アクションはコンテキストチェックされます。「信頼できるゾーン」はありません。
最低特権：最低限の期間（理想的にはJIT）に発行される最低限の権利。
役割に関するコンテキスト：権利は役割だけでなく、属性（テナント、地域、環境、リスク）にも依存します。
職務の分離（SoD）：個別の開始、承認、実行、監査。
Policy-as-Code：バージョン管理、テスト、レビューを含むコード内のポリシー。
3）アクセス成熟度モデル
1.RBAC（ロール）-開始-固定ロール（サポート、リスク、支払い、取引、Ops、 SRE、コンプライアンス）。
2.ABAC（属性）：属性の追加：テナント、地域、管轄、製品、チャネル、環境（prod/stage/dev）、時間、操作のリスククラス、KRI信号。
3.PBAC （policy-based）：集中型ポリシー「who/what/where/when/why」+conditions（例えば「、販売中-JITとチケット付き」）。
4）区分ドメイン（軸による軸）
4.1テナント/クライアント
アクセスおよび操作は、特定のブランド/オペレーター/アフィリエイトに限定されます。
クロステナント活動は、厳密に定義された非PII集計以外は禁止されています。
4.2地域/管轄
ポリシーはローカルライセンスとKYC/AMLルールを考慮しています。
プレイヤーデータ操作は、ストレージと処理の地理によって制限されます。
4.3環境（dev/stage/prod）
Prodは独立しています：個々のクレジット、ネットワーク、Bastion/PAM、「デフォルトで読み取り専用」。
チケットと変更ウィンドウで、prodのみJITへのアクセス。
4.4データクラス
PII/ファイナンス/ゲームテレメトリー/テクノロジスト-さまざまなレベルのアクセスとマスキング。
PIIのエクスポート-承認された暗号化されたワークフローとTTLのみを使用します。
4.5業務の重要性
P1/P2/P3クラス：係数の公開、手動オフセット、結論、PSPルーティングの変更-デュアル制御が必要です。
低リスク操作は、政治によって自動的に解除することができます。
5）特権レベル（階層）
ビューア：読み取り専用の集計データとマスクデータ。
Operator-設定を変更せずにrunbookプロシージャを実行します。
Contributor-Modifies非クリティカルドメインの構成。
承認者：アプリケーションの承認と高リスク操作（実行と組み合わせることはできません-SoD）。
管理者（JIT）：二重制御とセッション録音の下でまれなタスクのための短期プロモーション。
6） SoDと互換性のない役割
非互換性の例：- 結論を出し≠承認≠完了します。
- ボーナスキャンペーンを作成し≠販売≠変更限度額で有効にします。
- フィーチャーを開発≠、リリース≠ロールアウトをprodに適用します。
- PIIアップロードを要求し≠復号化≠承認します。
各ペアについて-改訂日を含む禁止と除外の公式ポリシー。
7） JITアクセスとPAM
リクエストに応じてエレベーション：ターゲット/チケット/期間を指定します。期限切れ後-自動リコール。
デュアルコントロール：P1/P2アクション-異なる機能の2つのアプリ。
セッションコントロール：重要なセッションの記録、異常アラート、PIIでの作業時のコピーペースト禁止。
ブレイクガラス：ハードリミットと必須のポストオーディットによる緊急アクセス。
8）サービスアカウントとAPIスコープ
最小スコープ；短命のトークン/証明書を分割するタスク/マイクロサービス。
秘密の回転、共有秘密の禁止。「ゴッドスコープ」禁止。
レート/クォータ、idempotencyキー、webhook署名（HMAC）の制限。
9）インフラストラクチャレベルのセグメンテーション
ネットワーク：セグメント分離（ドメインごと/テナントごと）、デフォルトの出力禁止、mTLS。
Kubernetes/Cloud：環境とドメインごとの名前空間/プロジェクト、危険なパターンを禁止するGatekeeper/OPA。
DB/キャッシュ：アクセスブローカー（DB プロキシ/IAM）、デフォルトでは読み取り専用、DDLはウィンドウ外のセールスで禁止されています。
リポジトリ：監査のためのTTLおよびWORMポリシーを使用して、クラスごとに異なるキー/バケット。
10）コードとしてのポリシー（PaC）
リポジトリ内のポリシー（Rego/YAML）、 PRレビュー、自動テスト（unit/e2e）、差分監査。
動的コンテキスト：時間、場所、KRIレベル、操作のリスクスコアリング。
監査における決定とポリシーへの参照を許可/拒否することの説明可能性。
11）ログと監査
完全性：who/what/where/when/why、 pre/post値、ticket ID。
変更不可：集中コレクション、WORM/不変、レコード署名。
接続：管理コンソール→API→データベース→外部プロバイダのチェーン。
監査SLA：制御/レギュレータ要求に対する応答率。
12）ダッシュボードとメトリクス（KPI/KRI）
アクセスKPI： JITと永続的権利の共有、平均特権期間、SoDでカバーされる％、アプリケーション処理時間、再認証のカバレッジ。
乱用のKRI：敏感な操作のバースト、大量アンロード、非定型の場所/時間、「zayavka→deystviye→otkat」シーケンス。
Exec-dashboard：リスクの高いロール、ブレークガラスイベント、トレンドのステータスを追跡します。
13）ポリシー例（スケッチ）
Prod- операции： 'allow if if role in {Operator、 Admin} AND env=prod AND jit=true AND ticket！=null AND sod_ok AND time in ChangeWindow'。
Экспорт PII： 'allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2'。
「action=UpdateRouting AND AND dual_control AND risk_assessment_passed AND rollback_plan_attached'」を許可します。
14）実装ロードマップ（8-12週間）
ネッド。1-2：操作/役割/データインベントリ、SoDマトリックス、データ分類およびセグメンテーションのドメイン。
ネッド。3-4： RBACベース、ロールカタログ、生産コンソール用JIT、 PaC （OPA/Gatekeeper）の開始).
ネッド。5-6： ABAC：テナント/リージョン/環境/データクラス属性；名前空間/プロジェクトの分離。
ネッド。7-8： PAM （JIT-elevation、セッション録音、ブレイクガラス）、DDL禁止およびデータベースブローカー、PII輸出ポリシー。
ネッド。9-10：高リスク操作のPBAC（結論、ボーナス、PSP）、デュアルコントロール、KRIアラート。
ネッド。11-12：四半期ごとの再認証、PaCオペレーションの100％高リスクのカバレッジ、レポートとトレーニング。
15）アーティファクト
ロールカタログ：ロール、最小権限、所有者。
SoDマトリックス：互換性のないロール/操作、例外、オーバーライドプロセス。
Policy Pack：テストとexample deny/allowを含むPaCポリシーのセット。
アクセスリクエストフォーム：目標、期間、オブジェクト（テナント/地域/環境）、リスクアセスメント、アプリ。
Sensitive Ops Register： P1/P2アクション、ウィンドウ、デュアルコントロール基準のリスト。
Audit Playbook：ログ、SLAレスポンス、ロールの収集と提供。
16） Antipatterns
永久的な管理者の権利と一般的なアカウント。
クロステナントは「便宜のため」にアクセスします。
isolation prod/stage/devはありません。
コード/コンソールで強制せずに紙のポリシー。
PIIは、暗号化とTTLなしの手動配置でエクスポートします。
再認定とハングの権利の欠如。
17）ボトムライン
特権セグメンテーションは「正しい役割」だけではありません。"これは多次元絶縁（テナント、地域、環境、データ、臨界性）+動的コンテキスト（ABAC/PBAC）+プロセス（SoD、 JIT、再認証）+技術的強制（PaC、 PAM、 ネットワーク/DB）です。このループは、エラーや悪用のリスクを劇的に低減し、安全な変更を加速し、プラットフォームを拡張および規制要件に耐えられるようにします。