Amazon FSx for Windows File Server で 転送中データの暗号化を強制してみた

2019年11月に発表された Amazon FSx for Windows File Server の転送中データの暗号化の強制を試してみました。
2019.11.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさま Xin chao !

以下のブログにある通り、Amazon FSx for Windows File Server (以降 FSx for Windows) のアップデートが大量に発表されました。

Amazon FSx for Windows 大量アップデートが来ました 2019年11月

今回は、転送中データの暗号化の強制を試してみたいと思います。

 

今回の環境

以下のように、既に Fsx for Windows の環境が構築済みの状態で試してみます。 また、踏み台サーバーとして、SMB 3 に対応している Windows Server 2016 と、SMB 3 に対応していない Windows Server 2008 R2 を用意しておきます。 踏み台サーバーは、いずれも Microsoft AD のドメインに参加済みとします。

 

やってみた

まずは、FSx for Windows 構築直後のデフォルト (=暗号化の強制が無効) の状態で試します。

Windows Server 2016 から FSx for Windows に接続 (暗号化の強制なしの状態)

Windows Server 2016 の踏み台サーバーに、Microsoft AD の Admin でリモートデスクトップ接続し、Z: ドライブとして FSx for Windows の共有フォルダを割り当てます。

New-PSDrive -Persist -Name Z -PSProvider FileSystem -Root \\amznfsx1234abcd.masawo-ad.test\Share

 

接続に使用されている SMB のバージョン、および、暗号化状況を確認すると、以下の通りとなります (管理者として実行する必要あり)。

Get-SmbConnection -ServerName amznfsx1234abcd.masawo-ad.test | Select-Object -Property *

SMB バージョン 3.1.1
暗号化 True (=有効)

 

以上確認できたら、共有フォルダの割り当てを一旦解除しておきます。

Remove-PSDrive -Name Z

Windows Server 2008 R2 から FSx for Windows に接続 (暗号化の強制なしの状態)

Windows Server 2008 R2 の踏み台サーバーに、Microsoft AD の Admin でリモートデスクトップ接続し、Z: ドライブとして FSx for Windows の共有フォルダを割り当てます。

New-PSDrive -Persist -Name Z -PSProvider FileSystem -Root \\amznfsx1234abcd.masawo-ad.test\Share

 

接続に使用されている SMB のバージョン、および、暗号化状況を確認すると... Windows Server 2008 R2 では Get-SmbConnection は使えませんでした。

SMB は接続元と接続先でサポートするバージョンが異なる場合、低い方のバージョンに合わせるため、Windows Server 2008 R2 の踏み台サーバー上に共有フォルダを一時的に作成し、Windows Server 2016 の踏み台サーバーから接続することで、Windows Server 2008 R2 で使用できる最上位の SMB バージョンと暗号化状況を確認したいと思います。 接続元の Windows Server 2016 の踏み台上で確認すると、以下の通りとなりました (fsx4w-bastion-2.masawo-ad.test が Windows Server 2008 R2 の踏み台サーバーになります)。

Get-SmbConnection -ServerName fsx4w-bastion-2.masawo-ad.test | Select-Object -Property *

SMB バージョン 2.1
暗号化 False (=無効)

 

以上確認できたら、共有フォルダの割り当てを一旦解除しておきます。

Remove-PSDrive -Name Z

暗号化を強制する

FSx for Windows のファイル共有へのアクセスに対して、暗号化を強制します。 Windows Server 2016 の踏み台サーバーから、以下を実行します。 ここで -ComputerName に指定するのは、これまで使用していた DNS name ではなく、Windows Remote PowerShell Endpoint になります。

$usSession = New-PSSessionOption -Culture en-US -UICulture en-US
Invoke-Command -ComputerName amznfsx5678efgh.masawo-ad.test -SessionOption $usSession -ConfigurationName FSxRemoteAdmin -scriptblock {Set-FSxSmbServerConfiguration -EncryptData $True -RejectUnencryptedAccess $True}

 

当初 AWS のドキュメントを見ながら検証した際、Invoke-Command が以下のようなエラーで成功せず困っていたのですが...

One or more errors occurred processing the module 'FSxRemoteAdmin' specified in the InitialSessionState object used to create this runspace. See the ErrorRecords property for a complete list of errors. The first error was: Cannot find the Windows PowerShell data file 'SmbLocalization.psd1' in directory 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\s
mbshare\ja-JP\', or in any parent culture directories.
+ CategoryInfo : OpenError: (amznfsxtrnf1n1e.masawo-ad.test:String) [], RemoteException
+ FullyQualifiedErrorId : PSSessionStateBroken

以下の情報をもとに、SessionOption を指定したところ一発解決しました。 ありがとうございます!

FSx for Windowsでvssやってみたら日本語EC2(Windows)だと失敗する件 - Qiita @ohechi

 

Windows Server 2016 から FSx for Windows に接続 (暗号化の強制ありの状態)

Windows Server 2016 の踏み台サーバーに、Microsoft AD の Admin でリモートデスクトップ接続し、再び Z: ドライブとして FSx for Windows の共有フォルダを割り当てます。 期待値としては、問題なく接続できるハズです。

New-PSDrive -Persist -Name Z -PSProvider FileSystem -Root \\amznfsx1234abcd.masawo-ad.test\Share

無事に接続できました。

 

Windows Server 2008 R2 から FSx for Windows に接続 (暗号化の強制ありの状態)

Windows Server 2008 R2 の踏み台サーバーに、Microsoft AD の Admin でリモートデスクトップ接続し、再び Z: ドライブとして FSx for Windows の共有フォルダを割り当てます。 Windows Server 2008 R2 は、暗号化をサポートする SMB 3 以降に対応していないため、期待値としては接続できないハズです。

New-PSDrive -Persist -Name Z -PSProvider FileSystem -Root \\amznfsx1234abcd.masawo-ad.test\Share

接続できませんでした (期待値通り)。

 

おわりに

Amazon FSx for Windows File Server で、転送中データの暗号化の強制を試してみました。

これまでサポートされていた、保管中データの暗号化に加え、よりセキュアに Windows ファイル共有のマネージドサービスを利用することができるようになったと思います。

ファイルサーバーの運用管理は、AWS 上で稼働させた場合でも意外と苦労しますので、運用負荷を下げられるマネージドサービスを積極的に活用したいですね。