開発者のためのセキュリティ：Infrastructure as Codeシリーズ「不適切な暗号化」

賢明な組織は「Infrastructure as Code（コードとしてのインフラ）」という概念を積極的に取り入れています。アプリケーションの構築以外においても、セキュアなコードを作成する上で、あなたのような開発者の貢献が大きな意味を持ちます。最初は道のりが長く感じられるかもしれませんが、周囲と差をつけるためには、その価値がある取り組みです。

「Coders Conquer Security」シリーズの次の章に進む前に、機密データ保存の脆弱性をテーマにしたゲーム形式のチャレンジに挑戦してみませんか？Kubernetes、Terraform、Ansible、Docker、CloudFormationの中から選んで、今すぐプレイしましょう。

結果はいかがでしたか？知識をさらに深めたい方は、ぜひこの先をお読みください。

今日、パスワードや個人情報、財務記録といった重要なデータを保存時にハッシュ化することは、あらゆるサイバーセキュリティ対策の要となっています。これは多くの面で、最後の砦であると同時に、最善の保護手段の一つとして機能します。たとえ攻撃者が他の防御を突破して重要なファイルを入手したとしても、適切にハッシュ化されて保存されていれば、攻撃者にとってそのデータはほとんど役に立たないからです。

これは、悪意のある内部関係者に対する強力な二次的保護としても機能します。暗号化されたファイルには、ネットワークの他の部分とは異なる鍵やパスワードを設定できるためです。その場合、システム管理者や管理者の認証情報を盗んだハッカーが保護されたディレクトリに侵入できたとしても、暗号化キーが別の場所に保管されていれば、そこにある暗号化ファイルを解読することはできません。

もちろん、あらゆる暗号化保護手法は、どれほど強力なコンピュータであっても解読できない強固な暗号化標準に依存しています。

なぜ安全でない暗号化は危険なのか？

コンピュータ技術において、強力な暗号化アルゴリズムの作成と、それを解読する技術は長年競い合ってきました。1977年、米国連邦政府は「Data Encryption Standard（DES）」を策定しました。これは当時のコンピュータの処理能力を考慮すると安全だと考えられていた56ビットのアルゴリズムでした。

しかしコンピュータは進化し、ネットワークで連携させることで処理能力をさらに高める手法が編み出されました。1999年、Electronic Frontier FoundationとDistributed.netは協力し、DESで保護された文書の暗号化をわずか22時間で公開解読しました。これにより、DESで保護されたあらゆる文書が安全ではなくなりました。

信じられないかもしれませんが、現在でもDESアルゴリズムや同様に脆弱な暗号化方式で重要なファイルを保護している組織が存在します。1999年当時は分散ネットワークが必要でしたが、今日では十分な性能を持つ単体のコンピュータであれば、短時間で解読が可能です。また、ハッカーはGPU（グラフィックス・プロセッシング・ユニット）を大量に並べた専用のクラッキングマシンを構築しています。GPUはこうしたタスクに極めて優れており、安価に入手してローカルでネットワーク化することも容易です。

今日、安全でない、あるいは脆弱な暗号化アルゴリズムで重要なファイルを保護することを選択すれば、ほとんどのハッカーが短時間でファイルを解読し、読み取れる状態にしてしまうでしょう。データ侵害が発生した場合、十分な保護がなされていなければ、最終的にファイルは流出するものと想定しなければなりません。

例えば、以下のKubernetesコードスニペットでは、NGINX Ingressコントローラーレベルで情報を保護するために脆弱な暗号化アルゴリズムが使用されています。

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: DES-CBC3-SHA
 ssl-protocols: "TLSv1.2"

この例では、情報を保護するためにDES暗号スイートが使用されています。しかし、攻撃者はこれを容易に解読し、機密情報にアクセスできてしまいます。

強力な暗号化アルゴリズムの使用が推奨されます。以下のKubernetesの例では、NGINX Ingressコントローラーレベルで情報を保護するために強力な暗号スイートが使用されています。

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: |
   ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
   ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
   ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
   ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
   ECDHE-RSA-AES128-SHA256
 ssl-protocols: "TLSv1.2"

この例では、攻撃者が機密情報にアクセスする可能性を排除するため、強力な暗号スイートが使用されています。

強力な暗号化による重要情報の保護

今日では、ほぼ解読不可能な強力な暗号化技術が利用可能です。2001年、米国国立標準技術研究所（NIST）はDESに代わる新しい暗号化技術を策定しました。Advanced Encryption Standard（AES）と呼ばれるこの技術は、128ビット、192ビット、256ビットという3種類の鍵長を使用します。256ビットのAES暗号化が最も安全ですが、3種類すべてが現在の技術ではほぼ完全に解読不可能と見なされています。スーパーコンピュータを用いたテストでは、AESで保護された文書のほとんどを解読するには、数千年にわたる絶え間ない計算が必要であることが判明しています。

重要なファイルを適切に保護するには、まずそれらを特定する必要があります。ネットワーク上のすべてを暗号化する必要はありません。絶え間ない暗号化と復号のプロセスによって、業務が遅延する可能性があるためです。しかし、人事記録、顧客データ、財務情報といった重要なファイルには、適切な保護が不可欠です。要するに、セキュリティとシステムの利便性のバランスを保つことが重要です。

また、そうしたデータはAES標準のいずれかで暗号化すべきであり、決して流出させてはならない極めて重要な情報については、256ビット暗号化まで検討する必要があります。

もう一つ考慮すべき点は、暗号化の追加はサイトにパスワードを増やすようなものだということです。つまり、権限を持つユーザーは暗号化キーを管理しなければなりません。これが業務のボトルネックにならないよう、キー管理プラットフォームの導入を検討し、キーの追跡と安全な保管を行うことをお勧めします。仮に一元的なキー管理を行わない場合でも、すべてのキーとパスワードを確実に保護し、権限のないユーザーが最も重要なデータ保管庫にアクセスできないようにしてください。

この脆弱性に関する詳細や、その他のセキュリティ上の欠陥から組織と顧客を守る方法については、Secure Code Warriorのブログをご覧ください。また、IaCチャレンジのデモをSecure Code Warriorトレーニングプラットフォームで体験し、サイバーセキュリティスキルを常に最新の状態に保つことができます。