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

この機能は、2023年第1四半期を通じてAdvanced Server Accessのすべてのお客様にロールアウトされます。Advanced Server Accessのチーム向けにこの機能を有効にするために、お客様側で何かする必要はありません。

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

ただし、プロジェクト内のサーバーのサブセットへのユーザーアクセスの付与が必要となる場合もあります。サーバーがどのプロジェクトに登録されているかに関係なく、すべてのデータベースサーバーへのアクセスを必要とするデータベース管理者のチームが存在するかもしれません。その場合、データベースサーバーのみを含む個別のプロジェクトを作成すると、チーム別にリソースをグループ分けするモデルは機能しなくなります。Okta PolicySyncは、アドバンストサーバーアクセスの管理者がユーザーグループに属性ベースのアクセス制御を適用できるようにします。これはリソースに対するロールベースのアクセスを付与するときに使用できます。これは、クライアントがKubernetesでオブジェクトを特定するためにラベルセレクターを使用する手順と同様に、ラベルをサーバーに適用し、セレクターをグループに適用することで行われます。

• PolicySyncの概念
• 詳細なサーバーアクセスのためにラベルとセレクターを使用する
• 関連項目

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ファイルも更新します。

ラベル

ラベルは個々のサーバーに適用されます。Advanced Server Accessのチームは、サーバーアクセスの分類や並べ替えにラベルを使用します。サーバーに適用できるラベルの最大数は50です。

チームの柔軟性を高めるために、ラベルは、「キー:値」の書式で保存されれます。例えば、サーバーにはenv:prodとregion:USという2つのラベルが存在する場合があります。ラベルが複数のソースに由来する可能性があるため、Advanced Server Accessは、ラベルのソースを特定するためのプレフィックスを自動的に追加します。env:prodラベルがAdvanced Server AccessのAPIに由来する場合、apiというプレフィックスが追加されてapi.env:prodと表示されます。これにより、同じラベルが複数のソースから追加された場合（たとえば、APIとAdvanced Server Accessのサーバーエージェント構成ファイルの両方がラベルを指定する場合）の競合を回避できます。

サーバーセレクター

サーバーセレクターは、グループに適用され、グループのメンバーが利用できるサーバーを制御します。プロジェクトにリンクされる各グループで利用できるサーバーセレクターの最大数は10です。サーバーセレクターには以下の特性があります。

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

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

前提条件

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

• Advanced Server AccessのチームのPolicySync機能フラグが有効化されている必要があります。

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

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

チームは、Advanced Server Accessのダッシュボードからラベルを追加できます。また、サーバーエージェントの構成ファイル（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（グループを更新する）］をクリックしてセレクターを保存します。

関連項目

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