trust

該当する場合

BlackShield はテナント管理者に具体的な ID 管理画面を提供します。Google、Okta、Azure AD の設定、有効化前の OIDC の検証、グループからロールへのマッピング、SCIM トークンのローテーション、ID 監査アクティビティの確認が可能です。

対象読者: IT 管理者、セキュリティ運用チーム、ワークスペース所有者、アクセス制御を検証する調達レビュー担当者所要時間の目安: 15-20 分

開始前に

ステップ 1

製品は定義されたプロバイダーのセットをサポートし、広範な展開の前に管理者に構成の検証を義務付けます。

`/identity` で、BlackShield はテナントレベルの OIDC プロバイダーとして Google、Okta、Azure AD をサポートします。
本番ユーザー向けにプロバイダーを有効にする前に、組み込みの検証ステップを使用します。
テナント OIDC が有効になっている場合は、`/login?tenant=acme-security&provider=okta` などのテナント固有の SSO リンクを配布して、匿名のテナント検出を行わずに承認された IdP にユーザーがアクセスできるようにします。
暗黙のデフォルトに依存するのではなく、デフォルトのロールと自動リンク動作を明示的に選択します。

成功の基準

暗黙のデフォルトに依存するのではなく、デフォルトのロールと自動リンク動作を明示的に選択します。

ステップ 2

BlackShield は、エンタープライズレビューでバイヤーが求めるライフサイクルコントロールを公開します。

成功の基準

ID 監査ストリームを使用して、ワークスペースの最近の OIDC および SCIM アクティビティを確認します。

ステップ 3

ユーザーアクセスとサービス資格情報の両方を迅速に削除できなければ、アクセス制御は完全ではありません。

ユーザーのロールが変更されたら、`/identity` でユーザーの IdP グループアクセスを削除または再マップします。
特権ユーザーの退職やスキャナーの所有権の変更後は、`/api-keys` で API キーを取り消すかローテーションします。
`/audit` と ID 監査を確認して、説明のつかない古い特権アクティビティが残っていないことを確認します。
OIDC が構成されていない場合は、`/tenant-rights` の [Invite User] オプションを介してユーザープロビジョニングを手動で管理し、チームメンバーを招待してシートの使用状況を監視します。

成功の基準

OIDC が構成されていない場合は、`/tenant-rights` の [Invite User] オプションを介してユーザープロビジョニングを手動で管理し、チームメンバーを招待してシートの使用状況を監視します。