Oracle Cloud Infrastructureドキュメント

Kerberos認証の使用

File Storageサービスは、強力な認証オプションを提供するKerberos認証を提供します。

NFS v.3 Unixセキュリティーは、NFSクライアントがユーザーの識別情報について真実であることを信頼し、基本的なセキュリティーのみを提供します。すべてのNFS呼び出しにおけるユーザーの識別情報は呼び出し元によって定義され、その識別情報は信頼できるサードパーティーによって検証されません。

Kerberos for NFSv3は、ホストとユーザーの両方に対して強力な認証を提供します。また、データの整合性を証明し、データが改ざんされないようにし、データのプライバシを保護することもできます。NFS v.3 UNIXセキュリティーでは、特殊なクライアントソフトウェアをインストールしたり、より多くのTCPポートを開いたりすることなく、データの整合性とデータプライバシを実現することはできません。

  • Kerberos対応ネットワーク内のユーザーおよびサービスは、プリンシパルと呼ばれます。Kerberosプリンシパルはprimary/instance@realmの形式です。詳細は、MIT Kerberosプリンシパル・ドキュメントを参照してください。
  • キー配布センター(KDC)は、プリンシパルを認証し、チケットを発行します。KDCは主体とそのパスワードのリストを保持します。
  • レルムは、1つのKDCでサポートされているすべてのプリンシパルで構成されます。

File Storageサービスでは、次のセキュリティ・オプションを使用して、RPCSEC_GSS (RFC2203)を介したKerberos認証をサポートしています。

  • NFSを介した認証にモードKRB5を使用
  • NFSを介した認証およびデータ整合性(転送中のデータの無許可の変更)にモードKRB5Iを使用します
  • NFSを介した認証、データ整合性およびデータ・プライバシ(転送中暗号化)にモードKRB5Pを使用します

機能

Kerberosのファイル・ストレージ・サービスのサポートには、次の機能が含まれます。

転送中暗号化

TLS v.1.2 (Transport Layer Security)暗号化を使用するかわりに、データ・プライバシを提供するKerberosモードKRB5Pを使用できます。TLS v.1.2暗号化では、オペレーティング・システムに応じて、oci-fss-utilsというパッケージをインストールするか、またはstunnelを使用する必要があります。マウント・ターゲットの暗号化されたNFS/TLS接続の数は制限されていますが、KerberosをKRB5Pオプションとともに使用すると、NFS over TLSでは不可能な規模で転送中暗号化を使用できます。

IPによるKerberosとセキュリティ

IPアドレスがOCIにあり、ホストが信頼できる場合、IPによるセキュリティはNFSエクスポート・オプションを使用して設定され、かなり安全です。NFSv3用の Kerberosは、ホストが信頼されない混在環境または環境に対して、より高いレベルのセキュリティーを提供できます。

同じエクスポートでKerberosとNFS AUTH_SYS認証を必要とするCIDRブロックを1つ構成できます。信頼できるネットワークからマウントするクライアントは Kerberosでマウントする必要はありませんが、信頼できないネットワークからマウントするクライアントは Kerberosを使用する必要があります。

LDAP参照および匿名アクセス

ユーザーがKDCにアイデンティティーを持っているが、LDAPサーバーに追加情報がない場合、またはLDAPが有効になっていない場合は、NFS操作が失敗するか続行できます。このような場合の動作は、マウント・ターゲットに対してLDAPを有効にするか、エクスポートに対して匿名アクセスを有効にするかによって異なります。

匿名アクセスは、デフォルトでは無効になっています。見つからないユーザーに関連付けられたNFSリクエストはすべて失敗します。

匿名アクセスが有効になっている場合、LDAPサーバーで見つからないユーザーに関連付けられたリクエストは、エクスポートのオプションで設定された「Squash UID」および「Squash GID」に進みます。マウントプロセスでLDAPサーバーに存在しないシステム Kerberos主体が使用され、破棄された権利によってNFSクライアントがファイルシステムをマウントするために使用するいくつかの読み取り専用操作が許可されている場合、匿名アクセスを許可することもできます。

Kerberos対応エクスポートのNFSリクエスト・シナリオ
マウント・ターゲットでLDAPが有効ですか。 LDAPレスポンス 匿名アクセス有効? スカッシュのエクスポートが有効ですか? NFSリクエスト
任意の 任意の 任意の はい(すべて)

エクスポートのオプションで設定された「Squash UID」および「Squash GID」を続行します。セカンダリ・グループ・リストがありません。
任意の 任意の 任意の はい(ルート)

エクスポートのオプションに設定された「Squash UID」および「Squash GID」は、ユーザー名がUID 0にマップされているLDAPレスポンスが成功した後にのみ続行されます。セカンダリ・グループ・リストがありません。

LDAP応答が0以外のUIDを返した場合は、返されたUID、GID、およびグループリストに進みます。
はい USERNAMEが一致 任意の いいえ LDAPサーバーから取得されたUID、GID、およびセカンダリグループリストを使用します。
はい 一致するUSERNAMEがありません はい いいえ エクスポートのオプションで設定された「Squash UID」および「Squash GID」を続行します。セカンダリ・グループ・リストがありません。
はい 一致するUSERNAMEがありません いいえ いいえ 権限エラーで失敗します。
はい 一致するユーザーがない以外のLDAPエラー 任意の いいえ 権限エラーで失敗します。
いいえ 適用されません はい いいえ

エクスポートのオプションで設定された「Squash UID」および「Squash GID」を続行します。
いいえ 適用されません いいえ いいえ 権限エラーで失敗します。
ノート

Kerberos対応エクスポートでは、マウント・ターゲットで「LDAPの有効化」が有効になっている場合、常に「グループ・リストにLDAPを使用」が使用されます。

詳細は、NFSエクスポート・オプションを参照してください。

前提条件

ファイル・ストレージでは、認証にKerberosを使用するための前提条件がいくつか必要です。

ユーザー単位でKerberos認証を使用するための要件は次のとおりです。

  • KerberosプリンシパルをUNIXアイデンティティにマップするための顧客管理LDAPインフラストラクチャ。詳細については、LDAP for Authorization Prerequisitesを参照してください。
  • MITやMicrosoft Active DirectoryなどのKDCを使用した顧客管理Kerberosインフラストラクチャ。
  • マウント・ターゲット名およびIPアドレスを解決できるDNSサーバー。順方向参照機能と逆方向参照機能の両方が必要です。
この図は、Kerberos認証に必要な顧客管理インフラストラクチャおよびOCI管理インフラストラクチャを示しています。
  1. TCP/UDPポート88を介した顧客管理KDCサーバーとの通信。
  2. NFSポート2048/2049/2050 (オプションで暗号化)を介したKerberos対応マウント・ターゲットとのセキュアな通信。
  3. TCP/UDPポート53を介した DNSサービスとの通信。
  4. アウトバウンド・コネクタで構成されたTCPポートを介した顧客管理LDAPサービスとの通信。デフォルト値はTCPポート636です。
  5. ファイル・ストレージ内の保存時にデータが暗号化されます。

LDAPインフラストラクチャ

ファイル・ストレージでは、UIDおよびGIDを使用してファイルへのアクセスが認可されます。ファイル・ストレージでは、LDAPを使用してKerberosプリンシパルをUIDおよびGIDSにマップします。LDAPインフラストラクチャ要件の詳細は、「認可にLDAPを使用するための前提条件」を参照してください。

ファイル・ストレージがLDAPからの認可情報を参照できない場合、KerberosプリンシパルのNFSアクセスが失敗する可能性があります。Kerberos認証はLDAPなしで使用できますが、すべての認証済み Kerberos主体は匿名として扱われます。詳細は、LDAP Lookups and Anonymous Accessを参照してください。

Kerberosキータブ

OCI Vaultに格納されるKerberosキータブは、次の構造のBase64エンコード文字列配列である必要があります: 

<principal, key version number, cipher type, symmetric key>

keytabの各エントリにはプリンシパルを1つのみ含めることができ、そのプリンシパルにはマウント・ターゲットの完全修飾ドメイン名(FQDN)をインスタンスとして含める必要があります。1つのプリンシパルには、異なる暗号化タイプまたは暗号を持つ複数のエントリを含めることができます。

たとえば、nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COMがkeytabのプリンシパルである場合、FSS_EXAMPLE.COMはレルム、fss_test.comはインスタンス、nfsはプライマリです。この例のマウント・ターゲットのFQDNは、krb_mt1.fss_test.comである必要があります。顧客管理DNSサーバーを使用している場合は、マウント・コマンドでこのFQDNを使用します。

ノート

デフォルトのInternet and VCN Resolverを使用する場合、ファイル・ストレージ・サービスは、マウント・ターゲットのホスト名と、マウント・ターゲットが存在するサブネットのFQDNを組み合せてFQDNを構築します。ホスト名は、作成後にマウント・ターゲットの詳細ページで変更できます。詳細は、マウント・ターゲットの管理を参照してください。

File Storageは、次の暗号セットをサポートしています。

  • aes128-cts-hmac-sha256-128
  • aes256-cts-hmac-sha384-192
  • aes128-cts-hmac-sha1-96
  • aes256-cts-hmac-sha1-96
ノート

OCI File Storageでは、最大1024バイトのKerberos keytabサイズがサポートされます。
重要

Kerberosを有効にする前に「Kerberos keytab」を検証して、無効なkeytabによる可用性の停止を回避します。マウント・ターゲットのKerberos構成を構成または確認すると、keytabを検証できます。

コンソール、CLIまたはAPIを使用してKerberosキータブを検証すると、ファイル・ストレージ・サービスによって次がチェックされます:

  • keytabサイズが1024バイトより大きい場合
  • keytabのバージョン番号が1281または1282でないこと
  • keytabにnullエントリが含まれている場合
  • keytabに主体名が異なるエントリがある場合
  • keytabに12を超えるエントリがある場合、これは最大値です。
  • keytabエンコーディングのタイプが次のいずれかでない場合:
    • ETYPE_AES128_CTS_HMAC_SHA1_96
    • ETYPE_AES256_CTS_HMAC_SHA1_96
    • ETYPE_AES128_CTS_HMAC_SHA256_128
    • ETYPE_AES256_CTS_HMAC_SHA384_192
ノート

KDCからバイナリ形式で抽出されたキータブは、Base64に変換してから、OCI Vaultでシークレットを作成するために使用する必要があります。変換されたキータブに貼り付けるときは、必ずシークレットの形式としてBase64を選択してください。

File Storageでは、バックアップ・キータブを使用したキータブのローテーションがサポートされています。詳細は、キーのローテーションを参照してください。

考慮事項と制限

ファイル・ストレージ認証にKerberosを使用する場合は、次の情報および制限を考慮してください。

  • ユーザーごとのKerberos認証の場合、ファイル・ストレージには、RFC2307 POSIXスキーマをサポートするLDAPサーバーを含む、顧客管理のLightweight Directory Access Protocol (LDAP)インフラストラクチャが必要です。
  • File Storageでは、最大1024バイトのKerberosキータブ・サイズがサポートされます。

  • File Storageは、次の暗号セットをサポートしています。

    • aes128-cts-hmac-sha256-128
    • aes256-cts-hmac-sha384-192
    • aes128-cts-hmac-sha1-96
    • aes256-cts-hmac-sha1-96
  • ファイル・システムのマウントには、rsizeまたはwsizeオプションはお薦めしません。これらのオプションの値を指定する場合、KRB5IまたはKRB5Pの使用時に、ファイル・ストレージによって256KBに減らすことができます。
  • Kerberos認証モードKRB5を使用する場合のファイル・ストレージのパフォーマンスは、AUTH_SYS認証を使用する場合とほぼ同じです。KRB5Pを使用するとパフォーマンスが大幅に低下し、KRB5Iを使用するとパフォーマンスがわずかに低下します。パフォーマンスは、クライアント構成およびファイルシステムによって異なる場合があります。

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

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

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

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

KerberosErrors[1m]{resourceType = "mounttarget", mtResourceName = "<mount_target_name>", errorType != "keytab_load_success"}.max() >= 1

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

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

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

必要なIAMポリシー

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

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

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

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

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

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

これにより、ユーザーは、Vaultシークレットを読み取り、検証のためにシークレットの一部を表示するファイル・ストレージ・コマンドを発行できます。File Storageは、検証のためにマウント・ターゲットを構成しているユーザーにプリンシパル、キー・バージョン番号および暗号化タイプを表示します。

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

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

  1. 次のようなポリシーを使用して、マウント・ターゲットの動的グループを作成します:

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    ノート

    動的グループに複数のルールがある場合は、必ずMatch any rules defined belowオプションを使用してください。

  2. Vaultシークレットへの読取りアクセス権をマウント・ターゲットの動的グループに付与するIAMポリシーを作成します:

    allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>