PolicySync：属性ベースのアクセス制御

これは早期アクセス機能です。有効にする場合は、Oktaサポートにお問い合わせください。

多くの場合、アドバンストサーバーアクセスのチームは、製品またはチーム別にグループ化されたプロジェクトにリソースを割り当てます。例えば、経理、マーケティング、エンジニアリングのチームごとに個別のプロジェクトが存在することがあります。アドバンストサーバーアクセスのサーバーに対してユーザーアクセスを付与する標準的な方法として、プロジェクト内でサーバーを登録し、ユーザーをグループに割り当て、その上でグループをプロジェクトに追加するといった手順があります。これによりグループのメンバーに、プロジェクトに登録されているサーバーすべてに対するアクセスが付与されます。

プロジェクト内のサーバーのサブセットへのユーザーアクセスの付与が必要となる場合もあります。例えば、サーバーがどのプロジェクトに登録されているかに関係なく、すべてのデータベースサーバーへのアクセスを必要とするデータベース管理者(DBA)のチームが存在することがあります。しかし、データベースサーバーのみを含む個別のプロジェクトを作成すると、チーム別にリソースをグループ分けするモデルは機能しなくなります。

Okta PolicySyncは、アドバンストサーバーアクセスの管理者がユーザーグループに属性ベースのアクセス制御（ABAC）を適用できるようにします。これはリソースに対するロールベースのアクセスを付与するときに使用できます。これは、クライアントがKubernetesでオブジェクトを特定するためにラベルセレクターを使用する手順と同様に、ラベルをサーバーに適用し、セレクターをグループに適用することで行われます。

PolicySyncの概念

PolicySyncで使用される主な概念として、承認済みのメインファイル、ラベル、セレクターの3つが挙げられます。以下のセクションでは、これらの概念について詳しく説明します。

承認済みのメインファイル

Okta PolicySyncは、OpenSSHデーモン（sshd）のAuthorizedPrincipalsFile構成オプションを使用します。AuthorizedPrincipalsFileの詳細については、sshd_configを参照してください。

PolicySyncが有効になると、アドバンストサーバーアクセスのサーバーエージェントは、ユーザーがアクセスできる各サーバー上の各ユーザーのhomeディレクトリにファイル.asa_authorized_principalsを作成します。このファイルが作成される場所は、アドバンストサーバーアクセスのサーバーエージェントのsftd.yaml構成ファイルにあるAuthorizedPrincipalsFileオプションを設定して変更できます。 場所を構成するには、サポートされるいずれかのユーザー別トークンを使用する必要があります。

  • %h：これはユーザーのhomeディレクトリパスに拡張されます。
  • %u：これはユーザーのユーザー名に拡張されます。
  • %U：これはユーザーのUIDに拡張されます。

例えば、アドバンストサーバーアクセスで認証済みのメインファイルをユーザーのhomeディレクトリに作成するよう構成するには、サーバーのsftd.yaml構成ファイルに以下を追加します。

AuthorizedPrincipalsFile: "%h/.asa_authorized_principals"

アドバンストサーバーアクセスのサーバーエージェントは、sftd.yamlで定義されるAuthorizedPrincipalsFile指令によってサーバーのsshd_configファイルも更新します。

注

アドバンストサーバーアクセスのサーバーエージェントsftdは、sshd_configを変更しますが、これを手動で、または自動化によって変更しないことを強くお勧めします。sshd_configの内容を変更すると、構成が非対応になったり破損したりする可能性があります。

ラベル

ラベルは個々のサーバーに適用されます。アドバンストサーバーアクセスのチームは、サーバーアクセスの分類や並べ替えにラベルを使用します。チームの柔軟性を高めるために、ラベルは、「キー:値」の書式で並べ替えられます。例えば、サーバーにはenv:prodとregion:USという2つのラベルが存在する場合があります。

ラベルが複数のソースに由来する可能性があるため、アドバンストサーバーアクセスは、ラベルのソースを特定するためのプレフィックスを自動的に追加します。例えば、env:prodラベルがアドバンストサーバーアクセスのAPIに由来する場合、apiというプレフィックスが追加されてapi.env:prodと表示されます。これにより、同じラベルが複数のソースから追加された場合（例えば、APIとアドバンストサーバーアクセスのサーバーエージェント構成ファイルの両方が1つのラベルを指定する場合）の競合を回避できます。

サーバーセレクター

サーバーセレクターは、グループに適用され、グループのメンバーが利用できるサーバーを制御します。サーバーセレクターには以下の特性があります。

  • セレクターがあるグループのユーザーは、そのセレクターのすべての要件を満たすサーバーのみにアクセスできます。
  • 複数のグループに属するユーザーは、それらのグループのセレクターの集合に属するサーバーにアクセスできます。
  • セレクターキーは任意でラベルのソースを指定することができます。
    • ソースが含まれる場合、そのソースに由来するラベルが含まれるサーバーのみが一致します。例えば、セレクターsftd.role=dbを使用した場合、sftd.yaml構成ファイルにラベルrole: dbが含まれるサーバーのみが一致します。
    • ソースが省略されている場合、指定されたラベルが含まれるすべてのサーバーが一致します。例えば、セレクターrole=dbを使用した場合、ラベルaws.role:dbまたはsftd.role:dbが含まれるすべてのサーバーが一致します。

ラベルとセレクターの構成については慎重に検討してください。ユーザーがプロジェクトで要塞へのアクセス許可を持っており、サーバーに接続できることを確認する必要があります。

サーバーへの詳細アクセス用にラベルとセレクターを使用する

前提条件

アドバンストサーバーアクセスのプロジェクトでラベルとセレクターを使用するには、以下が真である必要があります。

  • アドバンストサーバーアクセスのチームのPolicySync機能フラグが有効化されている必要があります。有効にする場合は、Oktaサポートにお問い合わせください。

  • プロジェクトのサーバーは、アドバンストサーバーアクセスのバージョン1.52.1以降のサーバーエージェントを実行している必要があります。

ラベルをサーバーに追加する

チームは、アドバンストサーバーアクセスのダッシュボードからラベルを追加できます。さらに、サーバーエージェントの構成ファイル（sftd.yaml）にラベルを直接追加することもできます。「PolicySyncラベル」をご覧ください。

  1. アドバンストサーバーアクセスのダッシュボードを開きます。
  2. ［Projects（プロジェクト）］をクリックしてプロジェクトを開きます。
  3. ［Servers（サーバー）］タブに移動します。
  4. サーバーの横に表示されるギア（ギアアイコン）をクリックし、［Edit Labels（ラベルを編集する）］を選択します。
  5. ［Add or Remove Labels（ラベルを追加または削除する）］フィールドに1つ以上のラベルを入力します。ラベルを入力するたびにキーボードのEnterキーを押します。
    注：ラベルの書式は「キー:値」である必要があります。
  6. ［Submit（送信）］をクリックしてラベルを保存します。

プロジェクトグループにサーバーセレクターを追加する

チームは、プロジェクトグループレベルでセレクターを割り当てることができます。セレクターを割り当てるには：

  1. アドバンストサーバーアクセスのダッシュボードを開きます。
  2. ［Projects（プロジェクト）］をクリックしてプロジェクトを開きます。
  3. ［Groups（グループ）］タブに移動します。
  4. サーバーの横に表示されるギア（ギアアイコン）をクリックし、［Edit（編集）］を選択します。
  5. ［Server Access（サーバーアクセス）］内の［Specific Servers（特定のサーバー）］を選択します。
  6. ［Server Selector Tags（サーバーセレクタータグ）］フィールドに1つ以上のラベルを入力します。ラベルを入力するたびにキーボードのEnterキーを押します。
    注：ラベルの書式は「キー:値」である必要があります。
  7. ［Update Group（グループを更新する）］をクリックしてセレクターを保存します。

関連項目

アドバンストサーバーアクセスのサーバーエージェントを設定する