今回は「Amazon EBS 暗号化」の三つ目の問題である「権限分離の不足」ということについて考えてみたいと思います。

前回、OSやネットワークのシステムの日常の管理には、暗号化されたような重要なファイルを参照する必要性はほとんどないので、リスク軽減のためには管理者(root)であってもデータを閲覧できないような仕組みが必要だと説明させていただきました。これは管理者(root)にすべての権限が集中することが、情報セキュリティ上の大きな問題であるということでした。

では、誰が暗号化の指示を出せばよいのでしょうか？

AWSの場合、マネージメントコンソールでチェックボックスをクリックするだけでEBSの暗号化がスタートします。つまり、マネージメントコンソールにログインできる管理者が暗号化の権限を握っていることになります。これもやはり権限の集中のリスクのひとつです。

最近の情報セキュリティ関係の事件では、不適切な人材に多くの権限を与えてしまったことが原因である場合が多くなっています。つまり、権限を分離できないシステムというのはそれだけで脆弱な要素があるということになります。一つの権限ですべてがコントロールできるというのは、便利な反面、管理者に多くの責任と負担を与えてしまいます。これは情報セキュリティ上は好ましくありません。

暗号化権限を分離して負担を減らす。

結論としては、セキュリティを高めて管理者の負担を減らすには権限を分離するしかありません。つまり、暗号化の権限だけ完全に他の管理者から分離するのです。これにより一極集中によるリスクを軽減し安全に重要なデータの管理をすることができます。

弊社のLinux暗号化ソリューション「Server-GENERAL」はデータ暗号化の権限を他の管理者から完全に分離してデータ管理者として独立運用できます。このことにより、他の管理者は暗号化されたデータを参照できなくなり、OSやクラウドの運用のみに集中でき負担を減らすことができます。この運用により、セキュリティもさらに強固になります。

　今回は「Amazon EBS 暗号化」の二つ目の問題である「一度、マウントしてしまえばデータのコピーは簡単」ということについて考えてみたいと思います。

これはまず、透過型暗号化と呼ばれる仕組みを理解する必要があります。透過型暗号化では暗号化されたボリュームをファイルシステムとしてマウントして利用します。マウント後は自動的にファイルの書き込み時に暗号化し、読み込み時に複合化を行います。このため利用者は暗号化を意識することなく暗号化機能を利用できます。

簡単に言えば、暗号化ボリュームをマウントしてしまえばOSからは普通のファイルシステムとして扱えるということです。これは透過型暗号化方式の致命的な弱点でもあります。

では、これは何が問題なのでしょうか？

まず、「マウント後は暗号化を意識せず利用できる」という利便性は逆にデータ漏えいの危険性を増すことになります。マウントしていなければ当然、暗号鍵が分からない限りファイルを参照することはできません。しかし、透過型暗号化では一度マウントしてしまえば通常は再起動時以外は再マウントをすることはありませんので、常にファイルを参照することができます。つまり、透過型暗号化はシステムの稼働中にセキュリティの一番のリスクがあります。なぜなら、稼働中は通常の読み込み権限さえあれば簡単にデータを参照することができるからです。

アクセス権限の設定は管理者(root)に対しては意味がない。

ファイルのアクセス権限の設定は管理者(root)以外のユーザでは非常に効果的にセキュリティを確保することができます。各ファイルシステムを適切なアクセス権限で運用するのは通常の対策としては問題ありません。しかし、OSの管理者はすべてのファイルの閲覧をができます。たとえ厳しいアクセス権限をファイルに与えていても、そのアクセス権限を変更できますし、権限のあるユーザになりすますこともできます。善良な管理者の立場から言えば、OSやネットワークのシステムの管理に暗号化されたような重要なファイルを参照する必要性はほとんどありません。にもかかわらず情報漏えい時に最も疑われやすい立場であり、そのリスクを負わなければならない極めて危険な状態にあります。

では、このリスクを軽減する方法はあるのでしょうか？

ー般的に管理者権限は、限られたメンバーしか利用出来なくなっています。そして、利用手続きを複雑にしたり、すべての利用記録を残したりすることで。このリスクを軽減しようと試みています。しかし、この方法では結局は特に管理者のアクセス権限は従来通りなので、悪意のある管理者のなりすましなどには全く効果がありません。

rootからのアクセスを拒否し、なりすましを検知する「Server-GENERAL」

弊社のLinux暗号化ソリューション「Server-GENERAL」は暗号化領域への管理者（root）ユーザからのアクセスを拒否し、また、rootからのなりすましも検知してアクセス拒否できます。つまり、信頼されたアプリケーションからのみアクセスを許可することで、透過型暗号化に高度なセキュリティを確保することを実現しています。

「Amazon EBS 暗号化」の一つの問題として、「暗号鍵を自分で管理することができない」ということがあります。
では、これはどういうことなのでしょうか？

暗号鍵とはデータを暗号化及び復号化するときに必要となる重要なもので、実際に暗号化するデータを保存するサーバとは別の場所に保存することが望ましいとされています。よくある例えですが金庫の横に鍵を置くような管理をしてはいけないということです。

「Amazon EBS 暗号化」では暗号鍵の管理はAmazon独自のキー管理インフラストラクチャであるAWS Key Management Serviceにより提供されています。これはサーバの外で暗号鍵を管理できますが、Amazon以外のサービスでは利用できません。「Amazon側で管理してくれるなら安心」という方もいれば、「暗号鍵は自社サーバで管理したい」とい方もいます。しかし、Amazon以外のクラウドやオンプレミスのサーバも利用している場合はどうすればいいのでしょうか？
その場合はAmazonの仕組みは当然利用できませんので、別の方法を考える必要がでてきます。つまり、特定サービスの利便性への依存はシステム全体の自由度を奪う可能性が高くなってしまいます。

セキュリティ面ではどうでしょうか？

通常は暗号鍵を他社に預けることはセキュリティ上は避けるべきことです。なぜなら、万が一暗号化鍵が取り出せなかったり、盗まれたりすることは０％ではありません。それはAmazonのサービスであったとしても同様です。コンプライアンス上厳しいセキュリティ監査をクラウドサービスを相手に要求するのは難しいでしょう。特にAmazonのような外国企業の運用するサービスであればなおさらです。リスクを最小限にしたいのであれば、最終的には自社管理のセキュアなネットワーク内で暗号鍵を管理できるようにするのが理想となるでしょう。

弊社のLinux暗号化ソリューション「Server-GENERAL」はAWSだけでなく、あらゆるクラウドサービス上のLinuxサーバを暗号化できます。また鍵管理サーバを自社で運用でき安全なネットワーク内で独自に運用可能です。