LDAPを使用した認可

ファイル・ストレージでの認可にLDAPを使用する方法について学習します。

Lightweight Directory Access Protocol (LDAP)をネットワーク情報サービスとして使用して、ファイル・ストレージ・サービスに認可情報を提供できます。LDAPを使用して認可情報を提供すると、次の利点があります。

UNIXユーザーおよびグループの一元管理。
最大256のUNIXグループのサポート。NFSリクエストのRPCヘッダー内で提供されるグループ・リストを使用するのではなく、セカンダリUNIXグループに対してLDAPを有効にした場合、16グループのAUTH_SYS制限の対象になりません。
LDAPインフラストラクチャは、Kerberosを使用する際のユーザー認証ごとの要件です。エクスポートですべてのスカッシュする場合など、すべてのKerberosシナリオでLDAPは必要ありません。

セカンダリ・グループ参照

ファイル・ストレージ・ファイル・システムでは、NFS操作のUID/GIDおよびセカンダリUNIXグループのリストを使用してアクセスが認可されます。デフォルトでは、AUTH_SYSはNFSリクエストのRPCヘッダー内に指定されたグループ・リストを使用します。

LDAP認可が有効な場合、ファイル・ストレージはNFSリクエストのRPCヘッダーのUNIX UIDを使用して、AUTH_SYSアクセス用のLDAPサーバーからセカンダリUNIXグループのリストを取得します。RPCヘッダーの既存のGIDLISTは、LDAPサーバーからのGIDLISTで上書きされます。LDAPサーバーからセカンダリUNIXグループを取得すると、承認要求で最大256個のグループを使用できます。

IDマッピングを使用したセカンダリ・グループ参照が有効で、構成されていないか、正しく構成されていないか、LDAPサービスが使用できない場合、ファイル・ストレージはリクエストで使用されるセカンダリ・グループ・リストを更新できません。これにより、アクセス権エラーが発生する可能性があります。

AUTH_SYSのNFSリクエスト・シナリオ
グループ・リストのLDAPは使用可能ですか?	LDAPレスポンス	スカッシュのエクスポートが有効ですか?	NFSリクエスト
任意の	任意の	はい(すべて)	すべてをスカッシングする場合は、エクスポートのオプションで設定された「Squash UID」および「Squash GID」に進みます。セカンダリ・グループ・リストがありません。
任意の	任意の	はい(ルート)	ルートをスカッシングする場合、UIDが0の場合のみ、エクスポートのオプションに設定された「Squash UID」および「Squash GID」に進みます。セカンダリ・グループ・リストがありません。
いいえ	適用されません	いいえ	RPCヘッダーからUID/GIDを処理します。
はい	UID一致	いいえ	LDAPサーバーから取得されたセカンダリグループリストを使用します。
はい	一致するUIDがないか、またはLDAPエラー	いいえ	RPCヘッダーからUID/GIDを処理します。セカンダリ・グループ・リストがありません。

重要

LDAPを認可に使用するには、マウント・ターゲットおよびエクスポート時にLDAPの有効化する必要があります。

Kerberos認証をLDAPとともに使用している場合、動作は若干異なります。詳細は、LDAP Lookups and Anonymous Accessを参照してください。

キャッシュ化

File Storageは、インメモリーのみのオンデマンド・キャッシュ・モデルを使用して認可情報を格納し、パフォーマンスを向上させ、LDAPサーバーの負荷を軽減します。

NFSリクエストが行われると、ファイル・ストレージはLDAPサーバーに接続して認可情報を取得します。File Storageは、後続のNFS操作で使用するために、認可情報を正または負のいずれかにキャッシュします。

次のオプションを使用して、LDAPのマウント・ターゲットを構成したときに、ファイル・ストレージがこの情報をキャッシュする期間を構成できます:

キャッシュ・リフレッシュ間隔(秒): エントリのリフレッシュを試行する前に、マウント・ターゲットがエントリをキャッシュに保持できる時間。セキュリティーへの影響とLDAPサーバーでの許容される負荷のバランスをとる値を選択します。
キャッシュ存続期間(秒): キャッシュされたエントリをマウント・ターゲットが使用できる最大時間。顧客インフラストラクチャの負荷または障害のためにキャッシュ・エントリを適時にリフレッシュできない場合は、接続がリストアされるまで古いエントリを使用すると便利です。LDAPキャッシュに古いエントリを保持する最も長い期間(なんらかの理由でLDAPサーバーが使用不可の場合など)に値を設定します。
負のキャッシュ存続期間(秒): マウント・ターゲットが、IDマッピング構成でユーザーが見つからない情報を保持する時間。ユーザーがLDAPデータベースに見つからない場合、マウント・ターゲットは、ユーザーが存在しないことを通知するエントリをキャッシュに配置します。セキュリティーへの影響とLDAPサーバーでの許容される負荷のバランスをとる値を選択します。

前提条件

要件:

RFC2307 posixスキーマをサポートするLDAPサーバーを含む、顧客管理のLDAPインフラストラクチャ。LDAPサーバーは、OpenLDAPまたはMicrosoft Active Directoryに基づくことができます。LDAPディレクトリのファイル・ストレージのサポートには、カスタマイズされた構成が必要になる場合があります。
ファイル・ストレージ・マウント・ターゲットがRFC2307準拠のユーザーおよびグループ情報の検索に使用できるLDAPサーバーへのログイン・アカウント。
- LDAPサーバーには次のユーザー属性が必要です。
  - ObjectClass: posixAccount– このオブジェクト・クラスは、ユーザーに次の属性を提供します。
  - uidNumber–UNIXユーザーID。
  - gidNumber– ユーザーのプライマリ・グループのUNIXグループID。
  - uid– ユーザーのユーザー名
- LDAPサーバーには次のグループ属性が必要です。
  - ObjectClass: posixGroup– このオブジェクト・クラスは、グループに次の属性を提供します。
  - gidNumber - グループのUNIXグループID
  - memberUid– このグループのメンバーであるユーザーのuid属性。この属性を複数回追加して、グループに複数のユーザーを含めることができます。
ヒント

LDAPスキーマのサポートをテストできます。
マウント・ターゲットがLDAPサーバーを含むホスト名を検索できるようにするDNSサーバー。

この図は、LDAP認可に必要な顧客管理インフラストラクチャおよびOCI管理インフラストラクチャを示しています。

TCP/UDPポート53を介した DNSサービスとの通信。
アウトバウンド・コネクタで構成されたTCPポートを介した顧客管理LDAPサービスとの通信。デフォルト値はTCPポート636です。
ファイル・ストレージ内の保存時にデータが暗号化されます。

LDAPインフラストラクチャ

ファイル・ストレージでは、マウント・ターゲットがLDAPSポート上のLDAPサーバーと通信できるように、アウトバウンド・コネクタが必要です。アウトバウンド・コネクタでは、LDAPサーバーの完全修飾ドメイン名(FQDN)、LDAPサーバーへのバインド・ユーザー名とパスワード、およびユーザーおよびグループの検索ベースを指定する必要があります。

ファイル・ストレージがLDAPサーバーにアクセスできるようにするには、次のことを確認します。

LDAPサーバーのファイアウォールでは、TCP 636 (デフォルト)を使用したファイル・ストレージ・マウント・ターゲットからのインバウンド・トラフィックを許可する必要があります。
使用中のセキュリティ・リストおよびNSGでは、マウント・ターゲットおよびLDAPサーバー・トラフィックを許可する必要があります。
DNSは、ホスト名を解決するためにマウント・ターゲットおよびクライアント用に構成されます。DNS構成オプションは次のとおりです:
- VCNでのデフォルトの解決およびホスト名でのOCI DNSの使用 - このオプションは、カスタムDNS名の柔軟性を提供しません。ホスト名の最後はoraclevcn.comで、VCNおよびサブネットのサブドメインがあります。詳細は、仮想クラウド・ネットワークのDNSを参照してください。
- プライベート・ゾーンでのOCI プライベートDNSの使用 - カスタム・ドメインのDNSゾーンは、OCI DNSでホストされます。OCIがDNSを完全に管理するため、このオプションを使用すると、独自のDNSサーバーを管理する必要はありません。ゾーンおよびレコードを管理する必要があります。詳細は、プライベートDNSを参照してください。
- 顧客管理DNSサーバーの使用 - VCNを作成するときに、「このVCNでDNSホスト名を使用」を選択しないでください。かわりに、次のいずれかの方法を使用して、独自のDNSサーバーを使用するようにVCNを構成します:
  1. 顧客管理DNSサーバーを使用するようにサブネットのDHCPオプションを構成します。
  2. VCN内のDNS問合せが顧客管理DNSサーバーに転送されるように、転送エンドポイントおよび転送ルールとともにVCNリゾルバを使用します。

ファイル・ストレージは、LDAPS認可のSSLv2、SSLv3、TLSv1またはTLSv1.1をサポートしていません。ファイル・ストレージでは、LDAPS認可用に次のOpenSSL暗号スイートがサポートされます。

DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
TLS_AES_128_CCM_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384

LDAPスキーマサポートのテスト

次の問合せ例を使用すると、ファイル・ストレージが、サポートされている構成を持つLDAPサーバーからRFC2307準拠のユーザーおよびグループ情報を検索できます。

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uid=<username>))' uidNumber gidNumber

$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uid=root))' uidNumber gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=root))
# requesting: uidNumber gidNumber
#

# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uidNumber: 0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uidNumber=<user_uid>))' uid gidNumber

$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uidNumber=0))' uid gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uidNumber=0))
# requesting: uid gidNumber
#
# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uid: root
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

ldapsearch -b <group_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixGroup)(memberuid=<username>))' gidNumber

$ ldapsearch -b 'ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixGroup)(memberuid=root))' gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(memberuid=root))
# requesting: gidNumber
#
# root, Groups, nfs_kerberos.fss_test.com
dn: cn=root,ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

ヒント

ファイル・システム・メトリックに基づいてアラームを作成すると、LDAP接続の問題を迅速に検出および診断できます。

モニタリングおよびアラーム

LDAPを使用するときは、問題を迅速に認識することが重要です。LDAPインフラストラクチャが正しく機能していない場合、NFSクライアントはエクスポートを介して使用可能なファイル・ストレージ・ファイル・システムへのアクセスを失う可能性があります。このような問題を検出するには、マウント・ターゲットのメトリックにアラームを設定することをお薦めします。アラームは、インフラストラクチャの問題を数分以内に警告できます。

LDAP接続エラーおよびLDAPリクエスト・エラーから構築されたアラームは、マウント・ターゲット、アウトバウンド・コネクタおよび顧客管理LDAPインフラストラクチャ間の接続の問題を検出します。

次の問合せ例は、LDAP接続用のアラームの作成に使用できます。

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

メトリックのモニタリングおよびアラームの使用の詳細は、モニタリングの概要を参照してください。アラームの通知の詳細は、通知の概要を参照してください。

必要なIAMポリシー

ファイル・ストレージは、LDAPサーバーのパスワードVaultシークレットにアクセスする必要があります。マウント・ターゲットを構成するユーザーとマウント・ターゲット自体の両方に読取りアクセスが必要です。

重要

これらのポリシーは、認可にLDAPを使用するようにマウント・ターゲットを構成する前に作成する必要があります。

Vaultシークレットを管理するためのポリシー

Vaultシークレットを作成するユーザーまたはグループに権限を付与します。詳細は、Vaultシークレットの管理を参照してください。

マウント・ターゲット構成を有効にするポリシー

次のようなポリシーを使用して、マウント・ターゲット権限でLDAPを構成するユーザーまたはグループに付与します:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID> }

これにより、ユーザーは、構成中に検証のためにVaultシークレットを読み取り、シークレットの一部を表示するファイル・ストレージ・コマンドを発行できます。

マウント・ターゲットにシークレットの取得を許可するポリシー

File Storageサービスにはシークレットを読み取る機能が必要です。ファイル・ストレージでは、リソース・プリンシパルを使用して、特定のマウント・ターゲットのセットにVaultシークレットへのアクセス権を付与します。これは2ステップのプロセスであり、まずアクセスが必要なマウント・ターゲットを動的グループに配置し、次にその動的グループにシークレットを読み取るアクセス権が付与されます。

次のようなポリシーを使用して、マウント・ターゲットの動的グループを作成します:
```
ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
```
ノート

動的グループに複数のルールがある場合は、必ずMatch any rules defined belowオプションを使用してください。
Vaultシークレットへの読取りアクセス権をマウント・ターゲットの動的グループに付与するIAMポリシーを作成します:
```
 allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>
```

次のステップ

次のステップは、「認可のためのLDAPの設定」を参照してください。

Oracle Cloud Infrastructureドキュメント