Azure NetApp Files でのデータ暗号化について

2025-05-06

Azure NetApp Files では、次の 2 つの異なる方法でデータが暗号化されます。

保存時の暗号化: データは、FIPS 140-2 準拠の標準を使用してその場で暗号化されます。
転送中の暗号化: データは、クライアントとサーバーの間で転送されるため、転送中またはネットワーク経由で暗号化されます。

保存時の暗号化について理解する

Azure NetApp Files の保存データは、次の 2 つの方法で暗号化できます。

単一暗号化では、Azure NetApp Files ボリュームに対してソフトウェアベースの暗号化が使用されます。
二重暗号化では、物理ストレージデバイスレイヤーでハードウェアレベルの暗号化が追加されます。

Azure NetApp Files では、標準の CryptoMod を使用して AES-256 暗号化キーが生成されます。 CryptoMod は、CMVP FIPS 140-2 検証済みモジュールの一覧に一覧表示されます。詳細については、 FIPS 140-2 証明書 #4144 を参照してください。暗号化キーはボリュームに関連付けられます。Microsoft プラットフォームマネージドキーまたはカスタマーマネージドキーを使用できます。

転送中のデータの暗号化について

Azure NetApp Files では、保存データをセキュリティで保護するだけでなく、エンドポイント間で転送中のデータをセキュリティで保護できます。使用される暗号化方法は、プロトコルまたは機能によって異なります。 DNS は、Azure NetApp ファイル内の転送中に暗号化されません。引き続き、Azure NetApp Files での SMB および NFS 暗号化、LDAP、およびデータレプリケーションについて学習します。

SMB 暗号化

SMB3.x プロトコルバージョンを使用する Windows SMB クライアントでは、 SMB 暗号化がネイティブにサポートされています。 SMB 暗号化はエンドツーエンドで実行され、AES-256-GCM/AES-128-GCM と AES-256-CCM/AES-128-CCM 暗号化スイートを使用して SMB 会話全体を暗号化します。

Azure NetApp Files ボリュームには SMB 暗号化は必要ありませんが、セキュリティを強化するために使用できます。 SMB 暗号化では、パフォーマンスのオーバーヘッドが増加します。 SMB 暗号化のパフォーマンスに関する考慮事項の詳細については、 Azure NetApp Files の SMB パフォーマンスのベストプラクティスに関するページを参照してください。

SMB 接続の暗号化を要求する

Azure NetApp Files には、すべての SMB 接続に暗号化を適用するオプションが用意されています。暗号化を適用すると、暗号化されていない SMB 通信が禁止され、SMB 接続に SMB3 以降が使用されます。暗号化は AES 暗号化を使用して実行され、すべての SMB パケットが暗号化されます。この機能を正しく機能させるには、SMB クライアントが SMB 暗号化をサポートしている必要があります。 SMB クライアントが暗号化と SMB3 をサポートしていない場合、SMB 接続は許可されません。このオプションを有効にすると、同じ IP アドレスを持つすべての共有で暗号化が必要になるため、暗号化の SMB 共有プロパティ設定がオーバーライドされます。

または、 Azure NetApp Files ボリュームの個々の共有レベルで暗号化を設定することもできます。

UNC のセキュリティ強化

2015 年、Microsoft は UNC セキュリティ強化 (MS15-011 および MS15-014) を導入し、SMB 共有間でリモートコードを実行できる可能性があるリモートネットワークパスの脆弱性に対処しました。詳細については、「 MS15-011 & MS15-014: グループポリシーのセキュリティ強化」を参照してください。

UNC のセキュリティ強化には、UNC パスをセキュリティで保護するための 3 つのオプションが用意されています。

RequireMutualAuthentication – スプーフィング攻撃をブロックするために ID 認証が必要/不要です。
RequireIntegrity – 改ざん攻撃をブロックするために必要/不要な整合性チェック。
RequirePrivacy – トラフィックスニッフィングを防ぐために、プライバシー (SMB パケットの合計暗号化) が有効または無効になっています。

Azure NetApp Files では、3 つの形式の UNC セキュリティ強化がすべてサポートされています。

NFS Kerberos

Azure NetApp Files には、AES-256-GCM/AES-128-GCM および AES-256-CCM/AES-128-CCM 暗号化スイートを使用した Kerberos 認証を使用して NFSv4.1 の会話を暗号化する機能も用意されています。

NFS Kerberos では、Azure NetApp Files では次の 3 つの異なるセキュリティフレーバーがサポートされています。

Kerberos 5 (krb5) – 初期認証のみ。NFS エクスポートにアクセスするには、Kerberos チケット交換/ユーザーサインインが必要です。 NFS パケットは暗号化されません。
Kerberos 5i (krb5i) – 初期認証と整合性チェック。NFS エクスポートにアクセスするには Kerberos チケット交換/ユーザーサインインが必要であり、中間者攻撃 (MITM) を防ぐために各 NFS パケットに整合性チェックが追加されます。
Kerberos 5p (krb5p) – 初期認証、整合性チェック、プライバシー。NFS エクスポートにアクセスするには、Kerberos チケット交換/ユーザーサインインが必要です。整合性チェックを実行し、各 NFS パケットに GSS ラッパーを適用してその内容を暗号化します。

各 Kerberos 暗号化レベルは、パフォーマンスに影響します。暗号化の種類とセキュリティの種類により安全な方法が組み込まれると、パフォーマンス効果が向上します。たとえば、krb5krb5iよりもパフォーマンスが高く、krb5i の方がkrb5pよりもパフォーマンスが高く、AES-128 のパフォーマンスが AES-256 よりも優れています。 Azure NetApp Files での NFS Kerberos のパフォーマンス効果の詳細については、「Azure NetApp Files NFSv4.1 ボリュームに対する Kerberos のパフォーマンスへの影響」を参照してください。

注

NFS Kerberos は、Azure NetApp Files の NFSv4.1 でのみサポートされています。

次の図では、Kerberos 5 (krb5) が使用されます。初期認証要求 (サインイン/チケット取得) のみが暗号化されています。他のすべての NFS トラフィックはプレーンテキストで到着します。

Kerberos 5i (krb5i; 整合性チェック) を使用する場合、トレースは NFS パケットが暗号化されていないことを示しますが、クライアントとサーバーがチェックサムを使用して転送されるデータの整合性を確保する必要がある GSS/Kerberos ラッパーがパケットに追加されています。

Kerberos 5p (プライバシー、 krb5p) は、GSS/Kerberos ラッパーを使用してトレースイメージに示すように、すべての NFS トラフィックのエンドツーエンドの暗号化を提供します。この方法では、すべての NFS パケットの暗号化を処理する必要があるため、パフォーマンスのオーバーヘッドが最も高くなります。

データのレプリケーション

Azure NetApp Files では、データ保護を提供するために、Azure のゾーンまたはリージョン間でボリューム全体をレプリケートできます。レプリケーショントラフィックは Azure クラウドに存在するため、転送はセキュリティで保護された Azure ネットワークインフラストラクチャで行われます。これは、パケットスニッフィングや中間者攻撃 (通信エンドポイント間の傍受または偽装) を防ぐためにアクセスが制限されます。さらに、レプリケーショントラフィックは FIPS 140-2 準拠 TLS 1.2 標準を使用して暗号化されます。詳細については、セキュリティに関する FAQ を参照してください。

LDAP 暗号化

通常、LDAP 検索とバインドトラフィックはプレーンテキストでネットワーク経由で通過します。つまり、ネットワークパケットをスニッフィングするアクセス権を持つすべてのユーザーは、ユーザー名、数値 ID、グループメンバーシップなどの情報を LDAP サーバーから取得できます。この情報は、ユーザーのなりすまし、フィッシング攻撃の電子メールの送信などに使用できます。

LDAP トラフィックは、LDAP 通信が傍受および読み取られるのを防ぐには、それぞれ LDAP 署名を介して AES と TLS 1.2 を利用するネットワーク経由の暗号化と TLS 経由の LDAP を利用できます。これらのオプションの構成の詳細については、「 Active Directory 接続の作成と管理」を参照してください。

LDAP 署名

LDAP 署名は、ユーザーとグループの UNIX ID をホストしている Microsoft Active Directory サーバー上の接続に固有です。この機能により、LDAP 接続をホストする AD サーバーに単純な認証およびセキュリティ層 (SASL) LDAP バインドの整合性検証が可能になります。署名では、Active Directory の Kerberos キー配布センター (KDC) サービスとの GSS-API 通信を使用するため、セキュリティ証明書の構成は必要ありません。 LDAP 署名では、LDAP パケットの整合性のみがチェックされます。パケットのペイロードは暗号化されません。

LDAP 署名は、グループポリシーを介して Windows サーバー側から LDAP 署名を使用して日和見的に構成することも (クライアントが要求した場合はサポートなし)、LDAP 署名を適用するように構成することもできます (必須)。 LDAP 署名を使用すると、通常はエンドユーザーには目立たない LDAP トラフィックにパフォーマンスのオーバーヘッドが発生する可能性があります。

Windows Active Directory では、LDAP 署名とシール (LDAP パケットのエンドツーエンド暗号化) を使用することもできます。 Azure NetApp Files では、この機能はサポートされていません。

LDAP チャネルバインディング

Windows Active Directory ドメインコントローラーでセキュリティの脆弱性が検出されたため、Windows サーバーの既定の設定が変更されました。詳細については、 Microsoft セキュリティアドバイザリ ADV190023を参照してください。

基本的に、管理者はチャネルバインドと共に LDAP 署名を有効にすることをお勧めします。 LDAP クライアントがチャネルバインドトークンと LDAP 署名をサポートしている場合は、チャネルバインドと署名が必要であり、レジストリオプションは新しい Microsoft パッチによって設定されます。

既定では、Azure NetApp Files では、LDAP チャネルバインドが日和見的にサポートされます。つまり、クライアントがサポートする場合は LDAP チャネルバインドが使用されます。チャネルバインドがサポートまたは送信されない場合、通信は引き続き許可され、チャネルバインドは適用されません。

SSL 経由の LDAP (ポート 636)

Azure NetApp Files の LDAP トラフィックは、すべてのケースでポート 389 を通過します。このポートは変更できません。 LDAP over SSL (LDAPS) はサポートされておらず、ほとんどの LDAP サーバーベンダーによってレガシと見なされます (RFC 1777 は 1995 年に公開されました)。 Azure NetApp Files で LDAP 暗号化を使用する場合は、TLS 経由で LDAP を使用します。

StartTLS 経由の LDAP

StartTLS 経由の LDAP は、2000 年に RFC 2830 で導入され、2006 年に RFC 4511 と LDAPv3 標準に組み合わされました。 StartTLS を標準にした後、LDAP ベンダーは LDAPS を非推奨と見なし始めました。

StartTLS 経由の LDAP では、LDAP 接続にポート 389 が使用されます。最初の LDAP 接続が確立されると、StartTLS OID が交換され、証明書が比較されます。その後、すべての LDAP トラフィックは TLS を使用して暗号化されます。次に示すパケットキャプチャは、LDAP バインド、StartTLS ハンドシェイク、およびその後の TLS で暗号化された LDAP トラフィックを示しています。

LDAPS と StartTLS には、主に次の 2 つの違いがあります。

StartTLS は LDAP 標準の一部です。LDAPS ではありません。その結果、LDAP サーバーまたはクライアントでの LDAP ライブラリのサポートは異なる場合があり、機能はすべてのケースで動作する場合と機能しない場合があります。
暗号化に失敗した場合、StartTLS では構成を通常の LDAP にフォールバックできます。 LDAPS は対応していません。その結果、StartTLS は柔軟性と回復性を提供しますが、正しく構成されていない場合はセキュリティリスクも発生します。

StartTLS での LDAP のセキュリティに関する考慮事項

StartTLS を使用すると、管理者は必要にじて通常の LDAP トラフィックにフォールバックできます。セキュリティ上の理由から、ほとんどの LDAP 管理者は許可しません。 StartTLS に関する次の推奨事項は、LDAP 通信をセキュリティで保護するのに役立ちます。

StartTLS が有効になっており、証明書が構成されていることを確認します。
内部環境では自己署名証明書を使用できますが、外部 LDAP の場合は証明機関を使用します。証明書の詳細については、「自己署名 SSL と証明機関の違い」を参照してください。
StartTLS を使用しない LDAP クエリとバインドを禁止します。既定では、Active Directory は匿名バインドを無効にします。

Active Directory セキュリティ接続

Azure NetApp Files ボリュームを使用する Active Directory 接続は、最初に利用可能な Kerberos 暗号化の種類として最も強力な AES-256 を試行するように構成できます。 AES 暗号化が有効になっている場合、ドメインコントローラー通信 (スケジュールされた SMB サーバーのパスワードリセットなど) では、ドメインコントローラーでサポートされている使用可能な最も高い暗号化の種類が使用されます。 Azure NetApp Files では、認証が試行された順に、ドメインコントローラー通信に対して次の暗号化の種類がサポートされています:AES-256、AES-128、RC4-HMAC、DES

注

Azure NetApp Files で弱い認証の種類 (RC4-HMAC や DES など) を無効にすることはできません。代わりに、必要に応じて、認証要求で使用が試行されないように、ドメインコントローラーからこれらを無効にする必要があります。ドメインコントローラーで RC4-HMAC が無効になっている場合は、適切な機能を実現するために Azure NetApp Files で AES 暗号化を有効にする必要があります。