Azure NetApp Files でのデータの暗号化について理解する
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 Cert #4144 をご覧ください。 暗号化キーはボリュームに関連付けられており、Microsoft のプラットフォーム マネージド キーまたはカスタマー マネージド キーを使用できます。
転送中のデータの暗号化について理解する
Azure NetApp Files では、保存データのセキュリティ保護だけでなく、エンドポイント間を転送中のデータもセキュリティ保護できます。 使われる暗号化方法は、プロトコルまたは機能によって異なります。 Azure NetApp Files では、DNS は転送中は暗号化されません。 以降では、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 の会話全体が暗号化されます。
SMB 暗号化は、Azure NetApp Files ボリュームに必要なものではありませんが、セキュリティを強化するために使用できます。 SMB 暗号化を使うと、パフォーマンスのオーバーヘッドが増加します。 SMB 暗号化のパフォーマンスでの考慮事項について詳しくは、「Azure NetApp Files での SMB のパフォーマンスに関するベスト プラクティス」をご覧ください。
SMB 接続に対する暗号化の要求
Azure NetApp Files には、すべての SMB 接続に暗号化を適用するためのオプションがあります。 暗号化を適用すると、暗号化されていない SMB 通信は禁止され、SMB 接続に SMB3 以降が使われます。 暗号化は AES 暗号化を使って実行され、すべての SMB パケットが暗号化されます。 この機能が正しく動作するには、SMB クライアントが SMB 暗号化をサポートしている必要があります。 SMB クライアントが暗号化と SMB3 をサポートしていない場合、SMB 接続は許可されません。 このオプションを有効にすると、同じ IP アドレスを持つすべての共有で暗号化が必要になるため、SMB 共有の暗号化に関するプロパティ設定がオーバーライドされます。
SMB 共有レベルの暗号化
または、Azure NetApp Files ボリュームの個々の共有のレベルで暗号化を設定することもできます。
UNC のセキュリティ強化
2015 年、Microsoft は、SMB 共有間でリモート コードを実行できる可能性があるリモート ネットワーク パスの脆弱性に対処するため、UNC のセキュリティ強化 (MS15-011 と MS15-014) を導入しました。 詳しくは、「MS15-011 と MS15-014: グループ ポリシーのセキュリティ強化」をご覧ください。
UNC のセキュリティ強化では、UNC パスをセキュリティ保護するために 3 つのオプションが提供されます。
RequireMutualAuthentication- スプーフィング攻撃をブロックするための ID 認証を必要または不要にします。RequireIntegrity- 改ざん攻撃をブロックするための整合性チェックを必要または不要にします。RequirePrivacy- トラフィックのスニッフィングを防ぐためのプライバシー (SMB パケットの全体的暗号化) を有効または無効にします。
Azure NetApp Files では、UNC のセキュリティ強化の 3 つの形式がすべてサポートされています。
NFS Kerberos
Azure NetApp Files では、AES-256-GCM/AES-128-GCM および AES-256-CCM/AES-128-CCM 暗号化スイートを使って、Kerberos 認証により NFSv4.1 の会話を暗号化する機能も提供されます。
Azure NetApp Files では、NFS Kerberos に関して、3 つの異なるセキュリティ フレーバーがサポートされます。
- Kerberos 5 (
krb5) – 初期認証のみ。NFS エクスポートにアクセスするには、Kerberos チケットの交換とユーザーのサインインが必要です。 NFS パケットは暗号化されません。 - Kerberos 5i (
krb5i) – 初期認証と整合性チェック。NFS エクスポートにアクセスするには Kerberos チケットの交換とユーザーのサインインが必要であり、中間者攻撃 (MITM) を防ぐために各 NFS パケットに整合性チェックが追加されます。 - Kerberos 5p (
krb5p) – 初期認証、整合性チェック、プライバシー。NFS エクスポートにアクセスするには Kerberos チケットの交換とユーザーのサインインが必要であり、整合性チェックが実行され、内容を暗号化するために各 NFS パケットに GSS ラッパーが適用されます。
各 Kerberos 暗号化レベルは、パフォーマンスに影響します。 暗号化の種類とセキュリティ フレーバーに組み込まれるセキュリティ保護方法が増えるほど、パフォーマンスへの影響が大きくなります。 たとえば、パフォーマンスは、krb5 の方が krb5i より優れ、krb5i の方が krb5p より優れ、AES-128 の方が AES-256 より優れています。 Azure NetApp Files での NFS Kerberos のパフォーマンスへの影響について詳しくは、「Azure NetApp Files NFSv 4.1 ボリュームでの Kerberos のパフォーマンスへの影響」をご覧ください。
Note
Azure NetApp Files では、NFS Kerberos は 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 トラフィックでは、それぞれ、AES を利用するネットワーク上の暗号化と、LDAP 署名と LDAP over TLS を介した TLS 1.2 を利用できます。 これらのオプションの構成について詳しくは、Active Directory 接続の作成と管理に関する記事をご覧ください。
LDAP 署名
LDAP 署名は、ユーザーとグループの UNIX ID をホストしている Microsoft Active Directory サーバーでの接続に固有です。 この機能により、LDAP 接続をホストしている AD サーバーへの簡易認証とセキュリティ層 (SASL) の LDAP バインドの整合性検証が有効になります。 署名では、Active Directory の Kerberos キー配布センター (KDC) サービスとの GSS-API 通信が使われるため、セキュリティ証明書の構成は必要ありません。 LDAP 署名では、LDAP パケットの整合性のみがチェックされ、パケットのペイロードは暗号化されません。
LDAP 署名は、グループ ポリシーを使って、LDAP 署名について日和見的に (なし - クライアントから要求された場合はサポート)、または LDAP 署名を適用するように (必要)、Windows サーバー側から構成することもできます。 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 チャネル バインドが使われます。 チャネル バインドがサポートまたは送信されない場合でも、通信は許可され、チャネル バインドは適用されません。
LDAP over SSL (ポート 636)
Azure NetApp Files の LDAP トラフィックは、常にポート 389 を経由します。 このポートを変更することはできません。 LDAP over SSL (LDAPS) はサポートされておらず、ほとんどの LDAP サーバー ベンダーはそれをレガシと見なしています (RFC 1777 は 1995 年に公開されました)。 Azure NetApp Files で LDAP 暗号化を使いたい場合は、LDAP over TLS を使ってください。
LDAP over StartTLS
LDAP over StartTLS は、2000 年の RFC 2830 で導入され、2006 年の RFC 4511 で LDAPv3 標準に組み込まれました。 StartTLS が標準になった後、LDAP ベンダーは LDAPS を非推奨と見なし始めました。
LDAP over StartTLS では、LDAP 接続にポート 389 が使われます。 最初の LDAP 接続が行われた後、StartTLS OID が交換されて、証明書が比較されます。その後は、すべての LDAP トラフィックが TLS を使って暗号化されます。 次に示すパケット キャプチャでは、LDAP バインド、StartTLS ハンドシェイク、およびその後の TLS で暗号化された LDAP トラフィックが示されています。
LDAPS と StartTLS の主な違いは次の 2 点です。
- StartTLS は LDAP 標準の一部ですが、LDAPS はそうではありません。 その結果、LDAP サーバーまたはクライアントでの LDAP ライブラリのサポートは異なる場合があり、機能はすべてのケースで動作する場合と動作しない場合があります。
- 暗号化が失敗した場合、StartTLS では構成を通常の LDAP にフォールバックできます。 LDAPS ではできません。 その結果、StartTLS ではある程度の柔軟性と回復性が提供されますが、正しく構成しないとセキュリティ リスクにもなります。
LDAP over StartTLS のセキュリティに関する考慮事項
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
Note
Azure NetApp Files で弱い認証の種類を無効にすることはできません (RC4-HMAC や DES など)。 必要に応じて、認証要求でこれらの使用が試みられないようにするには、代わりに、ドメイン コントローラーからこれらを無効にする必要があります。 ドメイン コントローラーで RC4-HMAC を無効にする場合は、適切な機能のために、Azure NetApp Files で AES 暗号化を有効にする必要があります。