暗号化
- 10 分
暗号化とは、情報を表示し、使用する権限が与えられている人を除き、情報を読めなくする数学的手法です。 データ ファイルは暗号化されることがあり、そのデータをネットワーク経由で処理するセッションも暗号化されることがあります。 現代のほとんどの Web サイトとサービスにおいて、トラフィックを暗号化し、セキュリティで保護する手段としてトランスポート層セキュリティ (TLS) が使用されています。 ブラウザーのアドレス行にプロトコル識別子 https:// (http:// ではない) が含まれており、セッションを保護しているサービスの証明書に、緑のチェックマークなど、何らかの "証明済み" アイコンが示されているとき、そのサイトでは TLS が使用されていることがわかります。
インターネットのセキュリティにおいて、また、パブリック クラウド プラットフォームでホストされているアプリケーションのセキュリティにおいて、暗号化は非常に大きな役割を果たします。 盗まれても使えなくする目的で保管中のデータを暗号化できます (Azure SQL Database や AWS S3 ストレージなどで)。また、クラウド サービス間やユーザーとクラウド サービスの間で、データが回線経由で転送されるとき、TLS で移動中のデータを暗号化できます。 最大の課題はキーの入手可能性にあります。 データが暗号化されているとき、その暗号化の解除キーをアプリケーションでは取得されるが、攻撃者には取得されないようにするには、どのような方法でどこに暗号化の解除キーを保管しますか? また、ブラウザーと Web サーバーの間で (あるいは、Web サーバーとデータベースの間やアプリケーションと、ユーザーの認証を担う、ID プロバイダーの間なども想定されます) トラフィックを暗号化する目的で TLS を使用するとき、潜在的攻撃者に公開することなくキーを入手できるようにするにはどうすればよいですか?
以上の質問に答えるために、デジタル暗号化の基本を確認し、キーの入手が認められている人にキーを入手させ、認められていない人には見せないようにするメカニズムについていくつか検討してみましょう。
対称暗号化
暗号化において、キーとは、メッセージの内容を変えるために (つまり、メッセージの暗号化または暗号化の解除に) 用いられる一連の数字です。 1 つのキーをデータの暗号化と暗号化の解除の両方に使用する対称暗号化は、暗号化の最も古い形式の 1 つです。 一般的には、データベースやクラウド ストレージ サービスで保存データの暗号化に使用されます。
年月と共に対称暗号化向けの一部のアルゴリズムが進化し、(これまでのところ) 誰もそれを破る方法を見つけていないこともあり、標準として採用されています。 そのようなアルゴリズムの 1 つが Advanced Encryption Standard、略して AES です。 アメリカ国立標準技術研究所で 2001 年に採用され、最新式のコンピューターの前では無力と見なされている Data Encryption Standard (DES) に取って代わりました。 256 ビット キーが使用される AES-256 は、AWS や Azure などのクラウド プラットフォームで、保管されているデータを暗号化する目的で広く利用されています。
AES-256 で暗号化したデータに対するブルートフォース攻撃では、解読に数十億台のスーパーコンピューターで数十億年かかりますが、これが問題をシンプルにしています。 現代のコンピューターでは、AES-256 で暗号化されたデータをキーなしで暗号化を解除することは不可能である、と言えば十分でしょう。 そのため、対称暗号化における最も重要な課題はデータの暗号化と暗号化の解除ではなく、キーは、それを必要とするすべての関係者が使用できるように保存されますが、使用できるのは、それを所有する権限のある者 "のみ" であるということです。
キーの保存とメンテナンス
データの暗号化 (と暗号化の解除) は簡単ですが、暗号化と暗号化の解除に利用されるキーをセキュリティで保護することは簡単ではありません。 秘密が保管されるあらゆるコミュニケーション システムにおいて、秘密自体が多くの場合、悪意を持つ人間の標的になります。
セキュリティ エンジニアは、キー ストレージ決して悪用されないよう、定評のあるキー管理サービスを利用することを組織に勧めます。 Azure Key Vault はそのようなサービスの一例です。 組織は PCI DSS (このモジュールの後半で説明します) などの標準や枠組みに準拠しますが、それを支援するのがキー マネージャーです。PCI DSS では、暗号化および暗号化の解除キーや暗号に関連するその他の秘密を定期的に変更する、または "ローテーションする" ことを求めています。 攻撃者が暗号化解除キー、データベース接続文字列、その他の「秘密」を入手できる可能性を減らすことにもつながります。
Azure Key Vault は、キー、パスワード、接続文字列、証明書、その他の秘密を保存することをセキュリティの高い方法でユーザーやアプリケーションに許可する SaaS サービスです。 ユーザーの認証には Microsoft Entra ID が利用されます。また、Azure SQL Database や Azure Storage など、他の Azure サービスと統合されます。 そこに保存されている秘密をアプリケーションで取得できるよう、API からもアクセスできます。 最大級の保護が必要であれば、連邦情報処理標準 (FIPS) 140-2 レベル 2 で認められたハードウェア セキュリティ モジュール (HSM) に任意で秘密を保管することができます。 HSM は共有したり、専用としたりすることができます。 重要なことですが、Azure Key Vault に保管されているデータを Microsoft が見ることはできません。
キーとその他の秘密が Key Vault に保管されたら、人間が介在しなくても値が自動的にローテーションされるようにシステムを設定できます。 これで組織は PCI DSS を順守できます。 セキュリティ問題が発生したり、定期的なセキュリティ監査を行ったりするとき、Key Vault は、組織全体に関連する IAM ログを生成する中心的な場所として機能します。
AWS では、AWS Key Management Service (KMS) という形式で同様のサービスを提供しています。 KMS は FIPS 140-2 レベル 2 で認められた HSM にも対応しており、また、監査可能なアクセス ログを生成する目的で AWS CloudTrail と統合されます。 KMS と Azure Key Vault がそれぞれのクラウド プラットフォームに統合されることで、そのようなプラットフォームでホストされているアプリケーションのセキュリティが厚くなります。 キーを使用するアプリケーションとキーを保管するキー コンテナーが同じ場所にあるため、データ センターを離れることがない秘密こそ、安全度の高い秘密と言えます。
非対称暗号化 (公開キーの暗号化)
対称暗号化は保存データの暗号化に優れていますが、暗号化されたメッセージを二者間で交換するときに問題を引き起こします。 Bob がメッセージを暗号化して Alice に送った場合、Alice はどのような方法でその暗号化を解除しますか? Bob が暗号化の解除キーを Alice に送ると、そのキーは危険にさらされる (盗まれる) 可能性があります。その場合、Bob と Alice が頼っていたセキュリティは実際、セキュリティでも何でもありません。 過去に、非公式にしていたつもりの通信がまったくそうではなかったために命を落とした人はたくさんいます。 たとえば、スコットランド女王のメアリーは、エリザベス女王の暗殺を企てたとき、共謀者に送ったメッセージの難読化暗号が弱かったため、処刑されました。1
暗号化の解除キーをすることなく、暗号化されたメッセージを交換するという課題は非実用的なものではありません。 それはブラウザーで https:// URL に接続するたびに行われます。あるアプリケーションがサードパーティの ID プロバイダーにアクセスするときにも行われますし、その他のケースもあります。 解決策は非対称暗号化です。 非対称システムでは、あるキーがメッセージの暗号化に使用され、別のキーがその暗号化の解除に使用されます。 この方法では、特定の受信者に宛てられたメッセージは公開キー、つまり、受信者が公に配布するキーで暗号化されます。 公開キーで暗号化されたメッセージの暗号化の解除には、2 つ目のキーのみを使用できます。 受信者はこの 2 つ目のキーを公開せず、秘密キーにします。 そのため、非対称キーは公開/秘密キーと呼ばれることがあります。
証明書
暗号化されたメッセージを Alice から受け取ることを Bob が望んでいる場合、Bob は自分の公開キーをメールで Alice に送るか、紙片に書いて Alice の机に置きます。 しかしながら、あるブラウザーで Web サーバーの公開キーが必要になった場合、また、そのブラウザーが接続していると "思っている" サーバーが本物であることを確認する必要がある場合、それはどのように行われますか? ここが証明書の出番です。
証明書の目的は、それを持つことで信頼されるエンティティに公開キーを提供することです。 証明機関 (CA) はこの証明書を生成する機関であり、証明を求める各個人や各法人の身元を物理的に確認する役目を任されています。 CA は必然的に、検証可能なコードですべての証明書に署名を付けます。
デジタル身分証明書の国際標準形式は 1998 年に確立された X.509 です。 図 3 からわかるように、X.509 には 3 つのバージョンがあります。新しいバージョンではフィールドが増えており、CSP が関係するトランザクションでは必須になりました。特に、1 つのサービスに複数のプロバイダーが関わり、そのような団体が証明書の発行元と署名者について追加情報を求めるとき、この追加フィールドが必要です。
![図 3: X.509 証明書の構造。[Microsoft 提供]](../../cmu-cloud-admin/cmu-cloud-security/media/fig8-3.png)
図 3:X.509 証明書の構造。 [Microsoft 提供]
ブラウザーで https:// URL を使用して Web サーバーに接続すると、TLS ハンドシェイクが開始します。このハンドシェイクで Web サーバーから公開キーを含む証明書が返され、本物であることが確認されます。 ただし、サーバーに送信する要求を暗号化する目的で公開キーが使用されることはありません。 (これは可能です。しかし、要求を暗号化すれば、Web サーバーにのみ秘密キーが与えられているため、サーバーでだけ要求の暗号化を解除できますが、サーバーからの応答については、公開キーを持つ者なら誰でも暗号化を解除できるため、安全ではありません)代わりに、ブラウザーでは、サーバーに送信する対称セッション キーを暗号化する目的で公開キーが使用されます。 その後、ブラウザーと Web サーバーの間で行われるあらゆる通信を暗号化 (および暗号化を解除) するとき、このセッション キーが使用されます。 このような次第で、TLS では、対称と非対称の暗号化の組み合わせが使用されています。非対称で対称キーを暗号化し、対称で要求と応答を暗号化します。
証明書が Web サーバー単独で使用されることはありません。 たとえば、ID プロバイダーで資格情報交換の暗号化に使用され、データベース サーバーでデータベース接続の暗号化に使用されます。 手短に言えば、移動中のデータを守るために、インターネット全体で使用され、データ センター内で使用されます。 クラウド管理者の仕事には、このような証明書の管理が含まれます。信頼できる CA から取得し、Web サーバー、データベース サーバー、ID サーバー、証明書が必要なその他の場所にインストールし、有効期限が切れる前に更新します。
準同型暗号
暗号作成法はプロセスとしても、産業としても進化していますが、ある有望なテクノロジが間もなく、データ セキュリティにおいて重要な役割を果たすことになるでしょう。それが準同型暗号 (HE) です。 暗号化されたエンティティから取得し、同時に実質的に暗号化を維持する手法です。
HE は非対称キー管理を置き換え、それに伴い、秘密キーの管理システムや保管庫も置き換えることになります。 認証を求めるユーザーは、本人すらアクセスできない有効な署名を含む証明書を渡すことができます。 この署名は、ハッシュ関数など、派生関数の結果として与えられます。 ユーザーの身元を確認するには、ID プロバイダーが暗号化されている検証キーを証明書機関から取得し、そのキーを利用し、証明書を実際に暗号化解除することなく署名を抽出します。 この手法の研究は進行中であり、現在のところ大部分は教育機関および研究機関に限定されています。
参考文献
- Simon Singh. The Black Chamber。 https://simonsingh.net/The_Black_Chamber/maryqueenofscots.html。