エンタープライズポリシーは、資格情報管理、メンバーの加入、SSOセッションアクセス、招待報酬に対して組織全体で適用されるルールを設定します。組織のオーナーと管理者は、組織のセキュリティ設定からこれらのポリシーを設定できます。
このチュートリアルでは、各ポリシーの範囲、設定方法、そして大規模展開の前にテストすべきことについて説明します。
始める前に
- 組織はEnterpriseプランを使用している必要があります。
- 組織のオーナーまたは組織管理者である必要があります。
- Apidog On-Premisesで利用可能なポリシーは、SaaSのドキュメントと異なる場合があります。
- 検証には、テストユーザー、架空の資格情報、および非本番プロジェクトを使用してください。
これらはワークスペースポリシーです。APIゲートウェイ、認証サーバー、サービスメッシュ、またはアプリケーションにおけるランタイムコントロールに取って代わるものではありません。
ステップ1:エンタープライズポリシーを開く
- Apidog組織を開きます。
- Organization Settings(組織設定)に移動します。
- Security(セキュリティ)で、Enterprise Policies(エンタープライズポリシー)を選択します。
組織のオーナーと管理者のみがエンタープライズポリシーを変更できます。
現在のページには、以下の4つのポリシーが含まれています。
- Auth Credential Policy(認証資格情報ポリシー)
- Invitation Credit Policy(招待クレジットポリシー)
- SSO Session Policy(SSOセッションポリシー)
- Member Email Domain Policy(メンバーメールドメインポリシー)
ステップ2:Auth Credential Policy(認証資格情報ポリシー)を設定する
Auth Credential Policyは、ユーザーがAPI認証、フォルダ認証、リクエスト認証、セキュリティスキーム、APIテストケース、およびテストシナリオを編集または保存する際に、サポートされている機密性の高い認証フィールドをチェックします。
生の値モードを選択する
認証機密フィールドでの生の値の禁止を設定します。
| モード | 結果 |
|---|---|
| オフ | ルールは適用されません |
| 警告 | ユーザーは警告を受けますが、保存できます |
| ブロック | ユーザーは非準拠の値を保存できません |
参照モードを選択する
認証でのローカル変数またはVault Secretのみを許可を、オフ、警告、ブロックの同じモードで設定します。
このコントロールが有効になっている場合、機密フィールドはローカル変数またはVault Secret参照を使用する必要があります。共有の初期値を持つ変数は、選択されたモードに応じて警告またはブロックされる場合があります。
Apidogは、資格情報ポリシーの許可された参照として以下を扱います。
- 空の値
- `{{variableName}}`のような変数参照
- `{{vault:key}}`のようなVault Secret参照
Vault値の表示を制御する
ユーザーがVault Secret値をUIに表示できないようにする場合、Vault Secretを平文で表示できないを有効にします。
ブロックする前にテストする
制御された展開のため:
- パイロットプロジェクトで警告を使用します。
- API Key、Bearer Token、Basic Auth、OAuth 2.0、および組織で使用されるその他の認証タイプをテストします。
- 生の値を承認された変数またはVaultパターンに置き換えます。
- 正当なワークフローが引き続き保存され、実行されることを確認します。
- 例外が対処されたら、ブロックに移行します。
このポリシーは、API Key、Bearer Token、BasicおよびDigest認証、OAuth 1.0および2.0、Hawk、AWS、NTLM、Akamai EdgeGrid、JWT Bearer、および組み合わせ認証の文書化された機密フィールドをカバーします。
ステップ3:SSO Session Policy(SSOセッションポリシー)を設定する
SSO Session Policyは、ユーザーが現在の組織のSSOを通じてサインインしている間にMy Teamsにアクセスできるかどうかを制御します。
- 組織に対してSSOが設定されていることを確認します。
- Enterprise Policiesで、SSO Session Policyを見つけます。
- SSOセッションでマイチームを制限するを有効にします。
- ポリシーを保存します。
有効にすると、その組織のSSOセッション中はMy Teamsが利用できません。
この設定はデフォルトで無効になっており、SSOが設定された後にのみ有効にできます。制限されたユーザーは、サインアウトして通常のサインイン方法を使用してMy Teamsにアクセスする必要があります。SSO組織に戻るには、再度SSOを通じてサインインする必要があります。
このポリシーは、アイドルタイムアウトや最大セッション期間の設定ではありません。現在の組織のSSOセッション内でのMy Teamsアクセスを分離します。
セッション境界をテストする
非管理者テストユーザーを使用します。
- 組織のSSOエントリーポイントを通じてサインインします。
- 組織が利用可能であることを確認します。
- My Teamsを開こうとして、制限メッセージを確認します。
- Sign out and switch(サインアウトして切り替え)を選択します。
- 通常の方法でサインインし、My Teamsが利用可能であることを確認します。
- SSO組織に戻るにはSSOが必要であることを確認します。
ステップ4:Member Email Policy(メンバーメールポリシー)を設定する
Member Email Policyは、組織メンバーシップを承認されたメールドメインに制限します。Apidogは、招待が送信されたアドレスだけでなく、ユーザーの最終的な認証済みメールをチェックします。
- 組織に対して1つ以上の許可されたメールドメインを設定します。
- Security > Enterprise Policiesを開きます。
- Member Email Policyを見つけます。
- ポリシーを有効にして保存します。
認証されたユーザーが組織メンバーになれるドメインを設定します。
同じ承認ルールが以下に適用されます。
- メール招待
- 招待リンク
- SSO
- SCIM
最終的な認証済みメールが許可されたドメインと一致しない場合、Apidogは参加試行を拒否します。組織、チーム、またはプロジェクトのメンバーシップは作成されず、ユーザーはシートを占有せず、メンバーリストやメンバーのエクスポートには表示されません。
拒否されたユーザーはドメイン不一致メッセージを受け取り、拒否は監査ログに記録されます。
組織が使用する各参加経路について、少なくとも1つの承認されたアドレスと1つの許可されないアドレスをテストします。
ステップ5:Invitation Reward Policy(招待報酬ポリシー)を設定する
Invitation Reward Policyは、適格な組織関連の招待が招待報酬クレジットを生成できるかどうかを制御します。
- Security > Enterprise Policiesを開きます。
- Invitation Reward Policyを見つけます。
- 招待報酬を有効または無効にします。
- 設定を保存します。
ポリシーを無効にすると、将来の適格な組織関連の招待が報酬クレジットを生成するのを停止します。すでに獲得されたクレジットは削除されません。
これは管理設定であり、アクセス制御またはセキュリティポリシーではありません。招待メール抑制機能として説明すべきではありません。
4つのポリシーすべてを確認する
小さなテストマトリックスを使用し、結果を記録します。
| ポリシー | ポジティブテスト | ネガティブテスト |
|---|---|---|
| Auth Credential | 承認されたローカル変数またはVault参照を保存する | 警告またはブロックモードで架空の生値を保存しようとする |
| SSO Session | SSOを通じてSSO組織にアクセスする | 制限されたSSOセッションでMy Teamsを開こうとする |
| Member Email | 承認された認証済みドメインで参加する | 許可されない認証済みドメインで参加しようとする |
| Invitation Reward | 選択された報酬状態を確認する | 無効にしたときに既存の獲得済みクレジットが変更されないことを確認する |
テスト後、ワークフローに関連する、サポートされているポリシー関連のメンバーシップまたは拒否イベントについて監査ログを確認します。
トラブルシューティング
| 問題 | 確認すべきこと |
|---|---|
| ユーザーが生の資格情報を保存できる | 正しい資格情報コントロールが有効でブロックに設定されていること、および値がサポートされている認証フィールドにあることを確認します。 |
| 承認された変数がブロックされる | より厳格なルールが、共有の初期値ではなく、ローカル変数またはVault Secretを要求しているかどうかを確認します。 |
| SSOセッション切り替えが利用できない | 組織に対してSSOが設定されていることを確認します。 |
| 有効な従業員が拒否される | 最終的な認証済みメールと、エイリアスや子ドメインを含む許可されたドメインリストを確認します。 |
| 既存のクレジットが消える | 招待報酬を無効にしても、すでに獲得されたクレジットは削除されないはずです。アカウントを記録し、サポートに調査を依頼してください。 |
重要な制限事項
- Auth Credential Policyは、文書化された認証フィールドとワークフローに適用され、すべての自由形式フィールド、スクリプト、ファイル、または外部リポジトリには適用されません。
- SSO Session Policyは、ある組織のSSOセッションにおけるMy Teamsを制限します。セッションタイムアウト、デバイスポリシー、またはネットワーク制御ではありません。
- Member Email Policyは参加を管理します。アドレスが一致しなくなった既存のメンバーが自動的に削除されるとは仮定しないでください。ただし、その動作が別途文書化されテストされている場合は別です。
- Invitation Reward Policyはセキュリティ制御ではありません。
- これらのポリシーのいずれも、デプロイされたAPIトラフィックに対する認証または認可を強制するものではありません。
関連するAPIガバナンスチュートリアル:
これらのチュートリアルは、エンタープライズAPIワークスペースを管理するための補完的なコントロールをカバーしています。
- APIガバナンスフレームワーク — オーナーシップ、制御、証拠、ライフサイクル決定を接続します。
- Microsoft Entra IDによるSAMLグループマッピング — IDプロバイダーグループからチームアクセスを割り当てます。
- シークレットスキャナー — サポートされているApidogアセットで露呈する可能性のある資格情報をレビューします。
- 監査ログ — 管理組織のアクティビティを調査およびエクスポートします。
- SCIMプロビジョニング — IDライフサイクルを通じて組織ユーザーを管理します。
- エンタープライズポリシー — 資格情報、メンバーシップ、SSOセッション、招待制御を設定します。
- セルフサービスAPIチーム — オーナーシップの監視を維持しつつ、メンバーがチームを作成できるようにします。
- GitHub Enterprise Cloud統合 — OpenAPIワークフローのためにサポートされているGHE.comリポジトリを接続します。
関連する公式ドキュメント:
