XenServer上の仮想マシンに暗号化されたコンテナを実装し、TrueCryptを使用してそれらを暗号化するタスクがありました。 ネットワーク上のトピックに関する有用な情報が見つからないため、この問題に関するメモを共有することにしました。 現時点では、ソリューションは運用されており、動作し、咳をしません。
ザダチニクは尋ねます-なぜヤギボタンアコーディオンですか？
多くの回答がありますが、最も一般的なのは、サーバーを物理的に悪用した場合に不要な目や人から暗号化する必要がある個人情報です。
仮想マシンでデータを暗号化しないのはなぜですか？
はい、なぜですか。 しかし、私の場合、約20台のマシンを暗号化する必要があり、再起動する場合は、20個すべてのコンテナーを接続する必要があり、あまり便利ではありません。 したがって、すぐにディスクを暗号化し、すべての仮想マシンをそのディスクに展開します。
言葉から行為へ
まず最初に、
XenServerをインストールする必要があります。 インターネットでは、このプロセスに関する一連のマニュアルなので、スキップします。
ハイパーバイザーまたは別のディスクがインストールされているディスクスペースが必要です。 情報が非常にプライベートであるため暗号化する必要がある場合、その損失はおそらくほとんどの人を幸せにしないため、そのようなことには別のディスクまたはレイドの配列を使用する方が良いと思います。
Linuxシステムと経験豊富なユーザー向けの標準的なディスク準備手順は簡単ではありませんが、念のため、次のことを思い出させてください。
ディスクをマークします：
mkfs.ext3を使用して、パーティションのファイルシステムを作成します。
fstabにマウントルールを追加すると、ジョブの半分が完了します。
/dev/sda1 /mnt/xen ext3 errors=remount-ro 0 0
truecryptをインストールします。
すべてがクールですが、xenにはデフォルトで十分なlibfuse.so.2がありません。 ハイパーバイザーはCentOS上の仮想マシンから制御されるため、これは私たちにとって大きな問題ではありません。
これで、暗号化されたコンテナを作成する準備がすべて整いました。
プロセス自体には時間がかかりますが、すべてはディスクサブシステムとサーバーの容量に依存します。
約2時間で300 GBのコンテナを作成しました...コンテナを作成した後、システムにマウントし、xenに転送します。
すべてが正しく完了したら、
truecrypt --listを実行すると、マウントされたコンテナのリストが表示されます。
1: /mnt/xen/vms1 /dev/mapper/truecrypt1 -
最後に、すべての準備アクションの目標は、コンテナをxenserverに転送することです。
uuidおよびdefault-SRは、xe pool-listおよびxe sr-listを介して認識できます。
これが魔法の終わりであり、
OpenXenManagerまたはXenCenterの助けを借りて、物理的な攻撃が発生した場合のプライバシーを心配することなく、暗号化されたコンテナに新しい仮想マシンを簡単に作成できます。
当然のことながら、再起動の場合は、ハンドルを使用してコンテナをマウントし、再度転送してから仮想マシンを起動する必要がありますが、実際にはそれらが試行されました。
PS：このノートは、初心者やそのような問題を解決したことがない人を対象としています。