セキュリティを制する者たち Infrastructure as Code シリーズ - 信頼できないソースからのコンポーネントの使用

2020年6月15日発行
マティアス・マドゥ博士著
ケーススタディ

セキュリティを制する者たち Infrastructure as Code シリーズ - 信頼できないソースからのコンポーネントの使用

2020年6月15日発行
マティアス・マドゥ博士著
リソースを見る
リソースを見る

Infrastructure as Codeシリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者のIaCセキュリティの旅をお手伝いすることができてよかったです。

皆さんはチャレンジをプレイしていますか?これまでのところ、あなたのスコアは何点ですか?始める前に、信頼できないソースからのコンポーネントを使用することの落とし穴について、皆さんがどれだけ知っているか見てみましょう。

まだやることがある?続きを読む

今日、私たちが注目する脆弱性を誘発する行為は、信頼できないソースからのコードを使用することであり、一見良さそうに見える行為が大きな問題を引き起こしています。オープンソースのコードやリソースを使用することには多くの利点があります。一般的には、専門家が自分のアイデアや作業、さらには完成したコードをGitHubのようなリポジトリに投稿し、プログラムやアプリを適切に動作させようと奮闘している他の人々が利用できるようにすることができます。完成したコードを使ってプログラムの機能を管理することで、開発者は新しいアプリケーションを作成するたびに車輪を再発明する必要がなくなります。

しかし、信頼性のない、検証されていない、あるいは潜在的に危険なソースからコードスニペットを使用することは、多くのリスクを伴います。実際、信頼されていないソースからのコードを使用することは、大きなセキュリティ脆弱性と小さなセキュリティ脆弱性の両方が、他の安全なアプリケーションに忍び込む最も一般的な方法の1つです。これらの脆弱性は、作成者が誤って誘発することもあります。また、潜在的な攻撃者によって悪意のあるコードが書かれている場合もあります。また、潜在的な攻撃者によって悪意のあるコードが書かれ、そのコードを共有することで、そのコードをアプリケーションに落とし込む被害者が現れることもあります。

信頼できないソースからのコードの使用がなぜ危険なのか?

例えば、開発者が急ぎで開発中のアプリケーションを設定する必要があるとします。この作業は非常に難しいものです。そこで開発者は、可能な限りの設定を行うために多くの時間を費やす代わりに、Google検索を行い、一見完璧に見える設定ファイルを既に完成させている人を見つけます。開発者はそのコードを書いた人のことを何も知らなくても、新しいアプリケーションに追加することは比較的簡単です。それは、Docker環境で2行を使って行うことができます。

RUN cd /etc/apache2/sites-available/ && ˶ˆ꒳ˆ˵
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/
9d372cfa8855a6be74bcca86efadfbbf/raw/˶ˆ꒳ˆ˵
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

これで、Dockerイメージがサードパーティの設定ファイルを動的に取り込むことになります。そして、そのファイルがテストされて問題ないことがわかったとしても、そのポインタが新しいアプリケーションのコードに組み込まれたということは、永続的な依存関係が存在することを意味します。数日後、数週間後、数ヶ月後に、元の作者やコードリポジトリを侵害した攻撃者によってファイルが変更される可能性があります。突然、共有された設定ファイルがアプリケーションに意図したものとは全く異なる動作を指示し、権限のないユーザにアクセスさせたり、あるいは直接データを盗んで流出させたりする可能性があります。

共有資源のより良い利用法

組織が外部ソースからのコードの使用を許可している場合、それが安全に行われることを保証するためのプロセスを導入する必要があります。外部のコードを使用する可能性を評価する際には、必ず安全なリンクを使用して公式のソースからコンポーネントを取得してください。その場合でも、外部のソースにリンクしてそのコードを取り込むことは絶対にしないでください。代わりに、承認されたコードは安全なライブラリに持ち込まれ、その保護された場所からのみ使用されるべきです。つまり、Docker環境では、コードは次のようになります。

src/config/default-ssl.conf /etc/apache2/sites-available/ をCOPYする。

リモートのサードパーティ製設定ファイルに頼るのではなく、それらのファイルのローカルコピーに頼ることになります。これにより、予期せぬ変更や悪意のある変更を防ぐことができます。

セキュアコードライブラリの使用に加えて、パッチ管理プロセスを導入し、ソフトウェアのライフサイクルを通じてコンポーネントを継続的に監視する必要があります。また、クライアント側とサーバ側のすべてのコンポーネントについて、NVDやCVEなどのツールを使用してセキュリティ警告をチェックする必要があります。最後に、使用されていない、または不要な依存関係や、外部のコードに付随してくる可能性のある機能を削除します。

これらの手順を踏むことで、開発者は、アプリケーションやコードに誤って脆弱性を誘発することなく、より安全に外部リソースを利用することができます。

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



リソースを見る
リソースを見る

著者

マティアス・マドゥ博士

マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社(Sensei Security)などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング(courses )の講師も務めています。

Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。

もっと知りたい?

セキュアコーディングに関する最新の知見をブログでご紹介しています。

当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。

ブログを見る
もっと知りたい?

開発者主導のセキュリティに関する最新の研究成果を入手する

ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。

リソース・ハブ

セキュリティを制する者たち Infrastructure as Code シリーズ - 信頼できないソースからのコンポーネントの使用

2020年6月15日発行
マティアス・マドゥ博士著

Infrastructure as Codeシリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者のIaCセキュリティの旅をお手伝いすることができてよかったです。

皆さんはチャレンジをプレイしていますか?これまでのところ、あなたのスコアは何点ですか?始める前に、信頼できないソースからのコンポーネントを使用することの落とし穴について、皆さんがどれだけ知っているか見てみましょう。

まだやることがある?続きを読む

今日、私たちが注目する脆弱性を誘発する行為は、信頼できないソースからのコードを使用することであり、一見良さそうに見える行為が大きな問題を引き起こしています。オープンソースのコードやリソースを使用することには多くの利点があります。一般的には、専門家が自分のアイデアや作業、さらには完成したコードをGitHubのようなリポジトリに投稿し、プログラムやアプリを適切に動作させようと奮闘している他の人々が利用できるようにすることができます。完成したコードを使ってプログラムの機能を管理することで、開発者は新しいアプリケーションを作成するたびに車輪を再発明する必要がなくなります。

しかし、信頼性のない、検証されていない、あるいは潜在的に危険なソースからコードスニペットを使用することは、多くのリスクを伴います。実際、信頼されていないソースからのコードを使用することは、大きなセキュリティ脆弱性と小さなセキュリティ脆弱性の両方が、他の安全なアプリケーションに忍び込む最も一般的な方法の1つです。これらの脆弱性は、作成者が誤って誘発することもあります。また、潜在的な攻撃者によって悪意のあるコードが書かれている場合もあります。また、潜在的な攻撃者によって悪意のあるコードが書かれ、そのコードを共有することで、そのコードをアプリケーションに落とし込む被害者が現れることもあります。

信頼できないソースからのコードの使用がなぜ危険なのか?

例えば、開発者が急ぎで開発中のアプリケーションを設定する必要があるとします。この作業は非常に難しいものです。そこで開発者は、可能な限りの設定を行うために多くの時間を費やす代わりに、Google検索を行い、一見完璧に見える設定ファイルを既に完成させている人を見つけます。開発者はそのコードを書いた人のことを何も知らなくても、新しいアプリケーションに追加することは比較的簡単です。それは、Docker環境で2行を使って行うことができます。

RUN cd /etc/apache2/sites-available/ && ˶ˆ꒳ˆ˵
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/
9d372cfa8855a6be74bcca86efadfbbf/raw/˶ˆ꒳ˆ˵
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

これで、Dockerイメージがサードパーティの設定ファイルを動的に取り込むことになります。そして、そのファイルがテストされて問題ないことがわかったとしても、そのポインタが新しいアプリケーションのコードに組み込まれたということは、永続的な依存関係が存在することを意味します。数日後、数週間後、数ヶ月後に、元の作者やコードリポジトリを侵害した攻撃者によってファイルが変更される可能性があります。突然、共有された設定ファイルがアプリケーションに意図したものとは全く異なる動作を指示し、権限のないユーザにアクセスさせたり、あるいは直接データを盗んで流出させたりする可能性があります。

共有資源のより良い利用法

組織が外部ソースからのコードの使用を許可している場合、それが安全に行われることを保証するためのプロセスを導入する必要があります。外部のコードを使用する可能性を評価する際には、必ず安全なリンクを使用して公式のソースからコンポーネントを取得してください。その場合でも、外部のソースにリンクしてそのコードを取り込むことは絶対にしないでください。代わりに、承認されたコードは安全なライブラリに持ち込まれ、その保護された場所からのみ使用されるべきです。つまり、Docker環境では、コードは次のようになります。

src/config/default-ssl.conf /etc/apache2/sites-available/ をCOPYする。

リモートのサードパーティ製設定ファイルに頼るのではなく、それらのファイルのローカルコピーに頼ることになります。これにより、予期せぬ変更や悪意のある変更を防ぐことができます。

セキュアコードライブラリの使用に加えて、パッチ管理プロセスを導入し、ソフトウェアのライフサイクルを通じてコンポーネントを継続的に監視する必要があります。また、クライアント側とサーバ側のすべてのコンポーネントについて、NVDやCVEなどのツールを使用してセキュリティ警告をチェックする必要があります。最後に、使用されていない、または不要な依存関係や、外部のコードに付随してくる可能性のある機能を削除します。

これらの手順を踏むことで、開発者は、アプリケーションやコードに誤って脆弱性を誘発することなく、より安全に外部リソースを利用することができます。

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



弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。