IBM Cloud Bare Metal Server の自己暗号化ドライブ (SED) を使ってドライブ盗難対策を実施する


# はじめに
万が一、ドライブが持ち出され、データ消去されないまま転売された場合でも、
情報流出が起こらないように `IBM Cloud Bare Metal Server` ユーザーとしてできる対策を実施します。

>こちらの内容を確認してみます。
[Enabling drive security by using Avago SafeStore Encryption Services](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-enabling-drive-security-by-using-avago-safestore-encryption-services&locale=dk)


# 自己暗号化ドライブ (SED) とは
SED は、暗号化ハードウェアを搭載しており、製造時にデータの暗号鍵が組み込まれます。
ドライブ内データ暗号化鍵（DEK）使って、デフォルトで読み書きデータを常に暗号化してくれます。

>[Introduction to Self-Encrypting Drives (SED)](https://www.pugetsystems.com/labs/articles/Introduction-to-Self-Encrypting-Drives-SED-557/)
A SED (or Self-Encrypting Drive) is a type of hard drive that automatically and continuously encrypts the data on the drive without any user interaction.
![Kobito.0cgaxE.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/9473bca7-5670-e967-0a4d-b372a43d630a.png "Kobito.0cgaxE.png")

ただし、データ暗号化鍵（DEK）がドライブ内に存在するため、このままではドライブが盗難にあった場合の対策になりません。
ドライブ盗難対策には、以下2つの方法が考えられます。

1. ドライブごとにパスワードを設定する
	- BIOS アクセスが必要になりますが、IBM Cloud では BIOS ログインを許可していません。
2. DEK を KEK (DEK の暗号鍵) で暗号化し、KEK を別途管理する
	- `IBM Cloud Bare Metal Server` では、RAID コントローラで KEK を作成・管理する方法で対策を実施できます。

>[5 Things to Know About Managing Encryption Keys for Self-Encrypting Drives in Lenovo System x Servers (5 Things To Know IBM Redbooks Blog)](https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_managing_encryption_keys_for_self_encrypting_drives_in_lenovo_system_x_servers?lang=en)
>![Kobito.UzmNGj.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/40de2196-a441-b7fb-6b23-e4cfe18938a4.png "Kobito.UzmNGj.png")


# IBM Cloud Bare Metal Server の注文
ストレージディスク構成の項目で、以下のように自己暗号化ドライブ (SED) を選択の上で、注文してください。
SED 搭載のベアメタルには、DEK の暗号化・KEK の管理を実施できる `AVARGO LSI MegaRAID 9361-8i RAID Controller` がプロビジョニングされます。

![Kobito.aNGz29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/4689bc4f-dd21-014e-70a3-7e15be5da661.png "Kobito.aNGz29.png")
![Kobito.DGmPfh.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/70580986-aaf6-2a10-3f5d-4e121ab9c574.png "Kobito.DGmPfh.png")
![Kobito.u0Hnj3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/273581ff-5221-afd2-ecc1-a2b86d6dce17.png "Kobito.u0Hnj3.png")


↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓


![Kobito.uUYX0h.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/d108b089-ccf7-f816-1d3a-4c514dc75d3c.png "Kobito.uUYX0h.png")


# MegaRAID Storage Manager (MSM) について

OS を Windows Server 2016 で注文したところ、 `MegaRAID Storage Manager (MSM)` がプリインストールされてきます。

>MegaRAID Storage Manager comes preinstalled on most supported operating systems

VMware vSphere ESXi 内で MSM 同等の処理をおこないたい場合は、 `storcli` を使うようにしてください。

>[ShinobiLayer: Bare Metal ServerでRAID構成を確認する(LSI MegaRAID/AVAGO MegaRAID編） - Qiita](https://qiita.com/testnin2/items/5a58de9e070dd146320d)

2019年12月にプロビジョニングしたベアメタルでは、MSM のバージョンは `16.02.00.04` でした。

>バージョン 16.02.00.04 のガイドは「[12Gb/s MegaRAID SAS Software User Guide, Rev. F](https://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/3rd-party/lsi/mrsas/userguide_12Gb_revf/54385-00_RevF_12Gbs_MegaRAID_SAS_SW_UserGd.pdf)」を参照してください。

[MegaRAID SAS 9361-8i Downloads](https://www.broadcom.com/products/storage/raid-controllers/megaraid-sas-9361-8i#downloads) から最新バージョンに自身でアップデートすることもできます。

>最新バージョンのガイドは [MegaRAID SAS 9361-8i Documentation](https://www.broadcom.com/products/storage/raid-controllers/megaraid-sas-9361-8i#documentation) を参照してください。

![Kobito.2NFV7I.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/c8806d98-530b-c369-8eeb-b22bba4679bf.png "Kobito.2NFV7I.png")

起動するとホストの探索が始まりますので、対象のホストをクリックします。
（始まらない場合は、 `Discover Host` から探索してください。）

![Kobito.8HkAzi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/72920110-eea1-148b-c1f8-f8ea889eaf58.png "Kobito.8HkAzi.png")

自分自身を対象としていますが、Windows Server 2016 の OS にログインするときに使用した認証情報を使って、ログインします。
（リモートサーバーを対象として MSM から複数サーバーを管理することもできます）

![Kobito.7l3fza.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/d88c508d-5cd0-cb7e-d000-6393539ed5fa.png "Kobito.7l3fza.png")


RAID コントローラ内で鍵管理をおこなえる機能 `MegaRAID SafeStore` が `Unlimited` でライセンスが有効化されています。

![Kobito.wffK8O.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/95b8555f-8a07-89a6-7deb-ca3575cfd4a3.png "Kobito.wffK8O.png")

SED 内のデータはデータ暗号鍵（DEK）を使ってデフォルトで暗号化されていますが、 `MegaRAID Storage Manager > Physical Tab > Properties > Drive Security Properties > Secured` が `No` になっているのは、あくまで DEK が暗号化されていないという意味です。（錠マークは、解除されている状態です。）

![Kobito.PKixXQ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/1eb0291a-bdee-5bc5-8b85-ad006d7cf71f.png "Kobito.PKixXQ.png")


# DEK を暗号化するための暗号鍵 KEK を作成

`Controller` を右クリックして、 `Enable Drive Security
` をクリックします。

![Kobito.emmzXe.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/b60ab887-c2e1-2492-c729-eaade71ad92e.png "Kobito.emmzXe.png")

ここで `Security Key Identifier` と `Security Key` を設定し、 DEK を暗号化するための暗号鍵 KEK を作成します。
>※ KEK はユーザー管理となっているため、鍵を紛失した場合は、残念ながらデータを復旧する術がありません...！！！

![Kobito.Y0aPCw.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/f0234245-d10f-2dbd-d310-57508a92ea22.png "Kobito.Y0aPCw.png")

以下のように `Controller` の鍵マークが黄色になれば、正しく鍵が作られたことがわかります。

![Kobito.dyEHzx.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/b8b158a0-c31e-5d61-b1bf-5db45bec8894.png "Kobito.dyEHzx.png")
![Kobito.y1Mi5c.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/b00b208c-f84b-6f86-70ca-94b0796cb627.png "Kobito.y1Mi5c.png")

# DEK を KEK で暗号化する
`FDE (Full Disk Encryption)` 機能を使って、DEK を KEK で暗号化します。

![Kobito.MIyVJi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/2cd2dee2-85a5-aa5a-f7ea-dbdca82e7e84.png "Kobito.MIyVJi.png")

既にデータが存在している状態から問題なく各ドライブ内の DEK を KEK で暗号化できます。
ただし無効化する際にはディスク内データ消去が必須となるので注意です。

![Kobito.4dBPBt.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/5ededdec-12bd-7727-37c0-331c6cf5786c.png "Kobito.4dBPBt.png")

更新ボタンを押したあとに、状態を確認すると `Secured` になっていて、錠マークもロックされたことがわかります。
この状態になるとドライブ盗難されたとしても、DEK が暗号化されているため、KEK を知らない限りドライブ内のデータを読み取ることはできません。
これだけの作業で対策を実施することができました。

![Kobito.mp4JUM.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/64d41293-1421-4b75-403a-a9cd89502305.png "Kobito.mp4JUM.png")
![Kobito.cnsS4g.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/cff95297-9c1a-88d0-25f4-26039bc68652.png "Kobito.cnsS4g.png")

# RAIDコントローラが交換となった場合は？
交換後に、交換前に設定していた `Security Key` を再設定することで、復旧可能です。
セキュリティキーを再設定後には、RAID などの設定についても、外部設定スキャンもしくは事前にエクスポート保存した設定ファイルから、その後インポートできます。

# SED 交換時の対応は？
RAID リビルドが必要ですが、通常リビルド自体は自動で走ります。
（交換前の準備としてディスクをオフラインにする設定作業はしたほうがよいです。）
交換後は自動でリビルドが走るため、リビルドが問題なく終わったかを確認します。
（KEK による DEK の暗号化もリビルドに合わせて自動で実施されます。）
ただし、交換対象の SED に対して `Instant Secure Erase` （ドライブ内 DEK 刷新によるデータ消去）を実施したい場合は、ドライブ交換前に1つドライブを追加して対応する必要があります。
追加されたドライブに対しては自動でリビルドが走りますので、RAID から外れた交換対象の SED に対して `Instant Secure Erase` を実施後にドライブを返却します。

> `Instant Secure Erase` 実施前
>![Kobito.Ym398A.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/fd386747-19db-15dc-01a7-69a07587a3eb.png "Kobito.Ym398A.png")
![Kobito.WYSJ2i.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/dd975bd8-51b8-6c79-21d1-3bd99d6e4a9f.png "Kobito.WYSJ2i.png")

> `Instant Secure Erase` 実施後
>![Kobito.kFC230.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/fa745458-8ac4-bac8-a822-93302d397562.png "Kobito.kFC230.png")

# 参考
VMware ESXi を MSM で管理する場合には、 VMware ESXi 側に `lsiprovider` が必要になります。
IBM Cloud で VMware vSphere Hypervisor を OS として払い出した場合は、すでに入っているはずです。

```vSphere_65_case
[root@host0:~] esxcli software vib get  -n lsiprovider
LSI_bootbank_lsiprovider_500.04.V0.59-0004
   Name: lsiprovider
   Version: 500.04.V0.59-0004
   Type: bootbank
   Vendor: LSI
   Acceptance Level: VMwareAccepted
   Summary: vmware-esx-provider-lsi-provider: ESX release
   Description: LSI Provider for ESX Server
   ReferenceURLs: 
   Creation Date: 2010-02-28
   Depends: 
   Conflicts: LSIProvider
   Replaces: LSIProvider
   Provides: cim.DMTF.DSP1030 = 1.0.0, cim.DMTF.DSP1013 = 1.0.0, cim.DMTF.DSP1015 = 1.1.0, cim.DMTF.DSP1002 = 2.0.0, cim.DMTF.DSP1028 = 1.0.0
   Maintenance Mode Required: False
   Hardware Platforms Required: 
   Live Install Allowed: False
   Live Remove Allowed: False
   Stateless Ready: False
   Overlay: False
   Tags: 
   Payloads: lsiprovider
```

#追記
MSM の最新版リリースが vSphere 6.5u2 リリース以前となっていたことが確認できました。
 
- vSphere 6.5 リリース - 2016年11月15日
- MSM 最新版リリース - 2017年6月24日
- vSphere 6.5u1 リリース - 2017年7月27日
- vSphere 6.5u2 リリース - 2018年5月3日
- Storcli 最新版リリース - 2019年12月21日
 
ESXi 6.5u2 を MSM で検出できない場合に状況を改善することはなかなか難しそうです。
 
>[ESXi6.5u2とMegaRAIDStorageManager｜SMATグループ](https://www.smat.ne.jp/memo/megaraid.html)
 
Storcli のほうは、vSphere 6.5u2 リリース後に最新版がリリースされているので、問題なさそうです。
[MegaRAID SAS 9361-8i Documentation](https://www.broadcom.com/products/storage/raid-controllers/megaraid-sas-9361-8i#documentation)「6.6.2.6 Controller Security Commands」の手順に沿って、セキュリティキーの作成後に暗号化を有効化できるはずです。