3 つのロールはアクセスモデルではありません。
多くのデリバリー製品はロールを短い一覧で提供します — 管理者、オペレーター、参照のみ — そして収まらないものはすべて管理者になります。証明書はトラフィック配下にあるという理由で証明書チームがトラフィックの全権を得ます。より小さいトークンが存在しないという理由で、監視連携が管理者トークンを受け取ります。
結果は明らかです。監査が「誰が変更できたのか」と尋ねたとき、正直な答えは「コンソールのほぼ全体」になります。職務分離は組織図の上にあり、製品の中にはありません。
2 つ目の失敗は操作面のずれです。画面では効くのに API では効かない権限は、権限ではなく助言です。
私たちのアプローチ
ロールが職務を、スコープが影響範囲を定めます。どちらもすべての操作面で適用されます。
3 ではなく 16 のロール
ロールは実際にチームが分かれる線に沿って切られています。トラフィック、WAF、ネットワーク、GTM、証明書、監視 — 区別が意味を持つ箇所ではマネージャーとユーザーの 2 種類を用意し、さらに触らずに見るための参照専用ロールとフロントエンド専用ロールがあります。
ロールの上に重なるスコープ
ロールは「どの種類のオブジェクトに触れてよいか」を示します。スコープは「そのうちのどれか」を示します。許可されたフロントエンドアドレス、許可されたバックエンドネットワーク、割り当てられた vService と vDevice。2 人の Traffic Manager が 1 台の装置で別々の環境を、互いのサービスを見ずに管理できます。
画面・CLI・API を通じて単一の権限モデル
対話型 CLI は画面と同じロールを適用します。Network Manager にはネットワークコマンドだけが見え、それ以外は見えません。REST アクセスも同じモデルで領域単位・フィールド単位に制御されます。永続 API トークンはロールに紐づきます。
すべての操作面が同じ監査証跡に書き込む
クリック、コマンド、API 呼び出しのいずれで行った変更も、欠落のない前後差分とともに 1 つの監査証跡に残ります。監査担当者の問い — 誰が、どこから変更し、以前はどうだったか — に対する答えは 1 つです。
機能
ロールモデルが扱う範囲と、その上に載るもの。
名前を持つ 16 の管理ロール
全一覧: Admin (スーパー管理者) · Traffic Manager · Traffic User · Traffic+WAF Manager · Traffic+WAF User · WAF Manager · WAF User · WAF Read-Only · Network Manager · Network User · GTM User · Certificate Manager · Monitor User · Read-Only User · Frontend User · Client。マネージャーとユーザーの区分が、設定する権利と運用する権利を分けます。
ネットワークスコープ — 許可されたフロントエンドアドレスとバックエンドネットワーク
ユーザーの到達範囲はオブジェクト種別だけでなくアドレスでも区切られます。公開できるフロントエンドアドレスと向け先にできるバックエンドネットワークがユーザーごとに列挙され、誤りは担当セグメントの内側に留まります。
リソーススコープ — 割り当てられた vService と vDevice
ユーザーには自分が所有する公開サービスと vDevice が割り当てられます。それ以外は読み取り専用なのではなく、表示されません。
証明書権限 — 管理と選択を分離
サービスに証明書を選ぶ権利と、証明書ライブラリを管理する権利は別の権利です。アプリケーションチームは正しい証明書でサービスを公開できますが、その背後の鍵をエクスポート・置換・削除することはできません。
シェルアクセスはユーザーごとのスイッチ
SSH 経由の CLI とブラウザ内 CLI は独立した 2 つのスイッチで、それぞれ最大セッション数を持ちます。SSH アカウントをどこにも作らずに、オペレーターへブラウザコンソールだけを渡せます。
ユーザーごとのクォータ: 帯域・CPU・コネクション
ロールは権限の集合だけでなくリソース上限も持てるため、テナント管理者が他の全員の分まで装置を使い切ることはありません。
フィールド単位の API 認可
REST アクセスは画面と同じモデルで領域単位・フィールド単位に制御されます。コンソールで見えないフィールドは、API からも読めません。
ディレクトリ連携の管理者と強力な認証
管理者はローカルアカウント、LDAP と Active Directory、RADIUS、またはアカウンティング付き TACACS+ で認証します。SMS やメールのワンタイムコードによる二要素認証、リカバリートークン、TR7 内部 PKI が発行する証明書を用いた mTLS 管理者ログインも利用できます。
作業環境の設定はユーザーに追従
言語、テーマ、ヘッダーバーの配置はユーザーごとに保存され、クラスターのどのノードに接続してもコンソールは同じ見た目になります。
運用上の深さ
アクセスモデルが監査を通るかどうかを決める部分。
職務分離を約束ではなく表現として
WAF、トラフィック、ネットワーク、GTM、証明書がそれぞれ別のロール系統であるため、規制業種の定番要件 — セキュリティポリシーを変える人とトラフィック経路を変える人は別であること — は、誰かが覚えておく手順ではなく設定になります。
本当に参照だけの参照専用ロール
Read-Only User、WAF Read-Only、Monitor User は、監査担当者・NOC 要員・ダッシュボードが「変更できてしまうロール」を必要としないために存在します。
委譲アクセスのための Frontend User と Client ロール
Frontend User は基盤に触れずに公開サービスを扱う人を対象とします。Client はクラウドクライアントの場合、つまりアカウントがサービスの運用者ではなく利用者に属する場合を対象とします。
管理プレーンのブルートフォース防御
パスワード複雑性を強制し、ログイン失敗は IP 単位および IP＋ユーザー名単位の有効期限付き上限で抑制されます。内蔵 CAPTCHA がこれを補強します。
管理サービスは個別にバインドしスコープする
HTTPS、SSH、FTP、SNMP はそれぞれ指定のアドレスとポートにバインドし、独自の許可ネットワーク一覧、独自の証明書、独自の TLS 最小・最大バージョンを持ちます。コンソールが TLS 1.3 を要求する一方で、まだ対応していない監視連携は別サービスへ TLS 1.2 で到達できます。
用途を限定したファイル転送アカウント
ファイル転送は共有アカウント 1 つで動きません。ログ書き出し、設定バックアップ、IP レピュテーションのオフライン配布、オフライン更新パッケージに個別のアカウントがあり、それぞれ自分のディレクトリしか見えません。
こんなときに
規制下の職務分離
銀行では WAF ポリシーの責任者とトラフィックの責任者を別人にし、それを証明する必要があります。WAF Manager と Traffic Manager は監査証跡も別の独立したロールなので、証明はヒアリングではなくレポートになります。
自分でサービスを公開するアプリケーションチーム
各チームには自分の vService と自分のバックエンドネットワークにスコープされた Traffic User ロールを渡します。変更申請なしに公開・運用でき、他チームのサービスには到達できません。
パイプラインと監視のトークン
CI/CD パイプラインには狭いロールに紐づく永続 API トークンを、監視システムには Monitor User に紐づくトークンを渡します。どちらも管理者権限を持たないため、トークン漏洩は範囲の限られた事象で済みます。
トラフィックを所有しない証明書チーム
Certificate Manager が鍵ライブラリと更新を管理し、アプリケーションチームはそこから選びます。秘密鍵をサービス公開チームへ渡す必要はありません。
よくある質問
TR7 には管理ロールがいくつありますか？
CLI は画面と同じ権限に従いますか？
2 人の管理者が 1 台の装置で互いを見ずに別々のサービスを管理できますか？
API トークンを管理者未満に制限できますか？
RBAC に追加ライセンスは必要ですか？
管理者はどのように認証しますか？
16 のロールをユーザーごとにスコープし、すべての操作面で適用
お客様自身の職務分離要件に照らして、ロールモデルを一緒に確認しましょう。