データベースを暗号化することの重要性を多くのSEは理解しています。技術をよく理解しているが上にその実装方法の設計には非常に慎重です。なぜなら、暗号化は単純な実装なら簡単ですが、高度なセキュリティを維持するのはとても難しいからです。

多くのプログラミング言語は暗号化のための関数が用意されています。またデータベース側にも独自のSQLによる暗号化関数があります。これらを利用すれば、誰でも暗号化を実現できます。しかし、実際に実現するとなると、どの暗号化関数で、どの暗号化のアルゴリズムを利用し、どのように暗号鍵の管理など実装しなければならないさまざまな問題が発生します。そして、選択した実装が本当に安全なのかを判断するのも時間を要する仕事です。

例えば商用版のMySQLでは独自のMySQL Enterprise Encryptionが用意されています。これは公開鍵暗号という高度な暗号化関数が利用できます。この場合でも公開鍵と秘密鍵の管理は十分に安全になるように考慮しなくてはなりません。

このように通常のシステム開発で暗号化を実装する場合、開発をする側に多大な労力が必要になります。しかし、弊社のLinux暗号化ソリューション「Server-GENERAL」ではアプリケーションの実装を変更することなく高度な暗号化を実現することができます。

前回、データベースの暗号化は可用性を考慮すると複数台の暗号化で、場合によっては暗号鍵の共通化などいくつか考慮すべきことがあるということでした。データベースは暗号化するにあたり、もう一つ暗号化を検討しなければいけない箇所があります。

それは、バイナリログ（トランザクションログ）です。

ログというと通常は単なるアプリケーションの動作の記録ファイルですが、データベースの場合はもっと重要な意味があります。それはデータの更新履歴がすべてその中に存在するということです。MySQLの場合、それはすなわちバイナリログと呼ばれるものであり、他のデータベースでも同様のファイルが存在します。このファイルを順番に辿ればデータを復元できてしまいます。つまり、データそのものがログファイルの中に含まれているので、これもセキュリティ上は重要な保護対象となります。

MySQLではレプリケーション時にはこのバイナリログを読むことでデータベースの複製を実現しますので、このバイナリログが安易に読み込まれてしまうことは情報セキュリティ上は避けなくてはいけません。しかし、以前にお伝えしたように単純な透過型暗号化では、バイナリログへの厳しいアクセス制限をかけることができませんし、もし、不正にコピーされたとしても記録が残りません。

弊社のLinux暗号化ソリューション「Server-GENERAL」はデータベースのバイナリログの保存フォルダを厳格なアクセス制限をかけたセキュリティポリシーで運用することが可能です。もし、管理者（root）がそのフォルダにアクセスしようとしても、閲覧できませんし、不正なアクセスとしてログに記録されます。

年金加入者の個人情報が流出し、改めてセキュリティ対策の重要性が浮き彫りになってきました。みなさんのビジネスでも大きな話題となっていることと思いますが、いかがでしょうか？　今回はかなり運用上の問題点が指摘されているようですが、システムを構築する側としては、お客様のセキュリティの意識を高めていくことがより重要になっていると再認識しました。本当に気をつけないといけないですね。

さて、今回はシステムの重要な要素であるデータベースのセキュリティについて考えてみたいと思います。データベースは重要なデータをすべて保存していますので、暗号化を考えるときに一番最初に対象となってくるものです。しかし、やはり安易に暗号化してしまうといろいろな問題が起きてきます。というのもデータベースは２４時間３６５日止まってはいけないというものが多く、セキュリティの中では可用性がもっとも重要視されてきました。このためクラスタやレプリケーションなど複数台を用いて可用性を高めることが通常は行なわれます。つまり、暗号化する場合、対象のサーバが複数になってしまうということです。

Amazon RDSも一応暗号化に対応していますが、使いやすいとは言えません。一番問題なのは現在利用中のRDSをそのまま暗号化できないということです。また、逆に一旦暗号化してしまうと元に戻すことができません。そもそもRDS自体がある程度ブラックボックス化しているので、カスタマイズの自由度が高いとは言えません。また、以前説明しました鍵管理、権限管理といった問題もEBS暗号化と同様ですので制約が多いと言えます。

実際、複数台のサーバを暗号化するとき、レプリケーションの場合はそんなに問題はありません。お互いが独立して暗号化しても通信プロトコルに変更はないので個別に暗号化すればよいということになります。しかし、DRBDなどのブロックデバイスの同期型のレプリケーションでは注意が必要です。なぜなら、この場合は暗号化された状態でデータのレプリケーションが行なわれるので、複数のサーバで同一の暗号鍵を使用する必要があります。いわゆる共有ディスク型のHAシステムも同様です。フェールオーバーして別のマシンが起動したときに同じ暗号鍵を使わないと復号化ができないからです。

弊社のLinux暗号化ソリューション「Server-GENERAL」は現在運用中のデータベースでも暗号化可能です。また、暗号化の停止もコマンド一つで簡単に運用できます。同期型のレプリケーションでも暗号鍵の共通化を指定できますので、柔軟なシステム構成に対応できます。

　今回は「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サーバを暗号化できます。また鍵管理サーバを自社で運用でき安全なネットワーク内で独自に運用可能です。

　現在、「Amazon EBS 暗号化」を用いて、AWS内のデータを暗号化してセキュリティを高めようと検討されている方も多いと思います。そのような中で本当にこの方法で安全なのかと疑問に思われている方も多いのではないでしょうか？ 弊社では長年、暗号化に関するソフトウエアを取り扱っており、多くの事例を把握しておりますが、暗号化にはいくつかのレベルがあり、高いセキュリティレベルを満たすには「Amazon EBS 暗号化」ではいくつかの問題があります。具体的には次の３点です。

１） 暗号鍵を自分で管理することができない
２） 一度、マウントしてしまえばデータのコピーは簡単
３） 権限分離の不足

という３点です。弊社の取扱商品の「Server-GENERAL」はこの３点を解決したLinux用の暗号化ソフトウエアになります。特にマウント後の不正アクセスを防ぐためにroot権限からのなりすましを検知し、アクセスを制限できますので、ハッキング対策として非常に有効な機能を備えています。