セキュリティポリシーの概念

セキュリティ管理者と代理セキュリティ管理者が作成できるルールは次のとおりです。

• サーバールール
• シークレットルール

• ラベルを使用するリソース

  ルールの作成時に、使用するラベルを選択し、ラベルに一致するサーバーを含めます。ラベルを使ってサーバーの範囲を定義すると、リソースに対するプリンシパルのアクセス方法を構成できるようになります。プリンシパルは、オンデマンドの個別アカウント、格納済みのローカルアカウント、またはその両方を使ってサーバーにサインインすることでリソースにアクセスできます。

• 名前別のリソース

  特定のリソースにポリシーを割り当てます（例：apiserver-prod / pamadmin）。

• System-generated labels（システム生成ラベル）：Okta Privileged Accessにサーバーを追加すると、ホスト名、サーバータイプ、オペレーティングシステム、AWS、Azure、またはGoogleクラウドプラットフォームアカウントIDなどの特性に応じて、システム生成のいくつかのラベルが自動的に作成されます。

• Custom labels（カスタムラベル）： サーバーエージェント構成ファイル（sftd.yaml）にラベルを直接構成できます。構成が済むと、このファイルはOkta Privileged Accessコンソールに表示され、ラベルを選択できます。サーバーエージェント構成ファイルにカスタムラベルを追加する方法については、「カスタムラベル」を参照してください。

  カスタムラベルはサーバーのアクセシビリティに影響を与える可能性があります。カスタムラベルは慎重に使用することをお勧めします。

チームの柔軟性を高めるために、ラベルは、キー/値のペアの形式で並べ替えられます。ラベルは、システム内で、またはsftd構成ファイルを通じて生成されます。Okta Privileged Accessは、ラベルのソースを識別するプレフィックスを自動的に追加します。たとえば、サーバーにはenv:prodとenv:testという2つのラベルが存在する場合があります。env:prodラベルがOkta Privileged Accessで生成された場合、システムプレフィックスはsystem.env:prodのようになります。同様に、env:testラベルがsftd構成ファイルから生成された場合、sftdプレフィックスはsftd.env:testのようになります。これにより、同じラベルが複数のソースから追加された場合（これはシステムとサーバーエージェント構成ファイルの両方でラベルが指定されている場合に起こる可能性があります）の競合を回避できます。