セキュリティを制する者たち Infrastructure as Code シリーズ。安全でない暗号技術

賢明な企業は、Infrastructure as Codeのコンセプトを採用していますが、アプリケーションの構築以外でも、安全なコードの作成に大きく貢献できるのは、あなたのような開発者です。最初は長い道のりに思えるかもしれませんが、仲間の中で目立つためには、その道のりに価値があります。

最新の「Coders Conquer Security」シリーズの次の章を始める前に、機密データ保存の脆弱性をゲーム化した課題をプレイしていただきたいと思います。今すぐプレイして、Kubernetes、Terraform、Ansible、Docker、CloudFormationの中から選んでください。

どうでしたか？もし、あなたの知識にちょっとした工夫が必要なら、ぜひ読んでみてください。

最近では、パスワード、個人情報、財務記録などの重要なデータを安置する際にハッシュ化することは、サイバーセキュリティ対策の要となっています。多くの意味で、これは最終的な防御策であると同時に、最良の防御策の一つでもあります。なぜなら、攻撃者が他の防御手段を突破して重要なファイルを入手したとしても、それらが適切にハッシュ化されて保存されている限り、攻撃者にとってはあまり意味がないからです。

また、暗号化されたファイルは、ネットワークの他の部分とは別のキーやパスワードを持つことができるため、悪意のあるインサイダーに対する強固な二次的保護としても機能します。このような場合、システム管理者や管理者の資格を侵害したハッカーなどは、保護されたディレクトリを閲覧することはできても、暗号化キーが別の場所にある場合、そこにある暗号化ファイルを解除することはできません。

もちろん、すべての暗号化保護方式は、最も強力なコンピュータでも解読できない強力な暗号規格を持つことが前提となります。

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

コンピュータ技術においては、強力な暗号化アルゴリズムを作ることと、それを解読することは、長い間競争してきました。1977年に米国連邦政府が開発したDES（Data Encryption Standard）は、56ビットのアルゴリズムで、当時のコンピュータの相対的な性能から見て安全であると考えられていました。

しかし、コンピュータは進化し、人々はコンピュータを共同でネットワーク化して、その能力をさらに高める方法を見つけた。1999年には、電子フロンティア財団とDistributed.netが協力して、DESで保護された文書の暗号化をわずか22時間で解除することに成功した。突然、DES暗号で保護された文書は、もはや安全ではなくなってしまったのだ。

信じられないかもしれませんが、一部の組織ではいまだに重要なファイルをDESアルゴリズムで保護していたり、同様に弱い暗号化保護を行っています。1999年当時、56ビットの暗号を解読するには分散型ネットワークが必要でしたが、現在では、十分な性能を持つスタンドアロン型のコンピュータであれば、少し時間をかければ解読することができます。また、ハッカーたちは、グラフィックス・プロセッサ・ユニット（GPU）のバンクを利用したクラッキング専用マシンを開発しました。これらのGPUは、その作業に非常に適しており、比較的安価に入手でき、ローカルにネットワークを構築することができます。

今日、重要なファイルを安全ではない、あるいは弱い暗号アルゴリズムで保護することを選択した場合、ほとんどのハッカーがそれらのファイルを破壊して読めるようにするまでに、それほど時間はかからないでしょう。もし、あなたがデータ漏洩の被害に遭った場合、十分に保護されていなかった場合は、いずれファイルが漏洩することを想定しなければなりません。

例えば、以下のKubernetesのコードスニペットでは、NGINX ingress controllerレベルの情報を保護するために弱い暗号アルゴリズムを使用しています。

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 controllerレベルの情報を保護するために強力な暗号スイートが使用されています。

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に代わる新しい暗号化技術を開発しました。AES（Advanced Encryption Standard）と呼ばれるこの技術は、128ビット、192ビット、256ビットの3種類の異なる鍵長を使用します。最も安全性が高いのは256ビットのAES暗号ですが、現在の技術では3種類ともほとんど解読できないとされています。スーパーコンピュータを使った実験では、AESで保護されたほとんどの文書を解読するには、何千年もの時間をかけて作業を続ける必要があるとされています。

重要なファイルを適切に保護するために、開発者はまずそのファイルを特定する必要があります。ネットワーク上のすべてのファイルを暗号化する必要はありません。常に暗号化と復号化を繰り返すことで業務が滞る可能性があるからです。しかし、人事記録、顧客データ、財務情報などの重要なファイルは十分な保護が必要です。基本的には、セキュリティと実用的なシステムのバランスを取ることが重要です。

そして、そのデータはAES規格のいずれかで暗号化されなければなりません。絶対に悪用されてはならない重要な情報の場合は、256ビットの暗号化も可能です。

もうひとつ考慮しなければならないのは、暗号化を追加するということは、サイトにパスワードを増やすようなものだということです。つまり、認証されたユーザーが暗号化キーを管理する必要があるということです。ワークフローのボトルネックになるのを防ぐために、鍵管理プラットフォームの導入を検討し、鍵を管理して安全に保管することをお勧めします。また、鍵の集中管理を行わない場合でも、すべての鍵とパスワードが保護されていることを確認し、最も安全なデータ保管庫に権限のないユーザーが立ち入らないようにしてください。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォーム内のIaC チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。