ブログ

Codeers Conquer Security Infrastructure as Codeシリーズ。セキュリティ機能の無効化

マティアス・マドゥ博士
2020年5月04日発行

昨今のサイバーセキュリティに対する脅威は、どこにでもあり、絶え間なく続いています。私たちの生活がデジタル化されればされるほど、サイバー犯罪者にとっての脅威は大きくなります。また、プログラムが導入された後に、攻撃対象のあらゆる側面を把握して防御しようとすることは、ほとんど不可能になっています。

このような症状を軽減するためのアプローチがありますが、その1つがInfrastructure as Code(IaC)のコンセプトを採用した賢明な組織です。もちろん、どのような開発でも、セキュリティ上の落とし穴があることは言うまでもありません。開発者は、アプリケーションをホストするための重要なインフラを生成するコードを作成しているため、プロセスのあらゆる段階でセキュリティを意識することが重要です。

では、クラウドサーバ環境に慣れていない開発者は、どのようにしてスキルアップし、ノウハウを学び、セキュリティ意識を高めて構築に臨めばよいのでしょうか。ここでは、IaCの一般的な脆弱性に取り組むため、「Coders Conquer Security」シリーズを作成しました。ここからの数回のブログでは、開発者が組織内でコードとしての安全なインフラを展開するためのステップに焦点を当てます。

さあ、始めましょう。

アメリカの旧西部には、山賊に襲われるのではないかと疑心暗鬼になっていた男の寓話がある。そのために彼は、頑丈な玄関ドアを設置したり、窓をすべて塞いだり、手の届くところにたくさんの銃を置いたりと、あらゆる種類のセキュリティに投資しました。それでも、ある夜、寝ている間に横のドアの鍵をかけ忘れて強盗に入られてしまった。窃盗団は、セキュリティの不備を見つけて、すぐにその状況を利用したのです。

インフラのセキュリティ機能が無効化されていることは、それとよく似ています。ネットワークに強力なセキュリティインフラがあったとしても、その要素が無効化されていては意味がありません。

飛び込む前に課題を提示します。

上のリンクをクリックすると、ゲーム性のあるトレーニングプラットフォームに移動し、今すぐ無効化されたセキュリティ機能の脆弱性の解消に挑戦することができます。(注意してください。しかし、ドロップダウンメニューを使えば、Docker、CloudFormation、Terraform、Ansibleから選ぶことができます)。)

あなたはどうでしたか?まだまだ課題があるという方は、ぜひ読んでみてください。

セキュリティ機能は、さまざまな理由で無効になることがあります。アプリケーションやフレームワークによっては、デフォルトで無効になっていて、機能を開始するためにはまずオンにする必要があります。また、管理者が特定のタスクをより簡単に実行できるように、特定のセキュリティ機能を無効にしている可能性もあります(例:AWSのS3バケットを公開する)。作業終了後、管理者は無効にした機能を再び有効にすることを忘れてしまうかもしれません。また、今後の作業を容易にするために、無効にしたままにしておくこともあるでしょう。

無効化されたセキュリティ機能が危険な理由

1つ以上の無効なセキュリティ機能を持つことは、いくつかの理由でよくありません。一つは、そのセキュリティ機能は、既知のエクスプロイト、脅威、または脆弱性から保護するためにインフラストラクチャリソースに搭載されています。それが無効になっていると、リソースを保護することができません。

攻撃者は常に、簡単に利用できる脆弱性を最初に見つけようとし、スクリプトを使って一般的な弱点を洗い出すこともあります。これは、泥棒が通りにあるすべての車をチェックして、鍵のかかっていないドアがないかどうかを確認するのと同じで、窓を破壊するよりもずっと簡単なことです。ハッカーは、一般的なセキュリティの防御策が不発であることに驚くかもしれません。しかし、そうなれば、それを悪用するのに時間はかからないでしょう。

第二に、優れたセキュリティを導入しておきながら、それを無効にしてしまうと、誤ったセキュリティ意識が生まれます。管理者は、誰かがその防御機能を無効にしたことを知らなければ、一般的な脅威から守られていると思うかもしれません。

無効化されたセキュリティ機能を攻撃者がどのように利用するかの例として、AWS S3のセキュリティ機能であるパブリックアクセスのブロックを考えてみましょう。Amazon S3のブロックパブリックアクセスを使えば、アカウント管理者やバケット所有者は、Amazon S3リソースへのパブリックアクセスを制限するための集中管理を簡単に設定することができます。しかし、S3バケットへのアクセス時に問題に遭遇した管理者の中には、できるだけ早くタスクを完了させるために、バケットを公開することを決める人もいます。もしそのセキュリティ機能を有効にするのを忘れてしまうと、攻撃者はそのS3バケットに保存されている情報に完全にアクセスすることができ、情報の漏洩だけでなく、データ転送料による余分なコストが発生してしまいます。

実際のコードを比較してみましょう。以下のCloudFormation snippetsをご覧ください。

ヴァルネラブル。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

確保。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

セキュリティ機能の無効化を防ぐ

無効にしたセキュリティ機能が組織に悪影響を与えないようにするには、ポリシーと実践の問題があります。非常に特殊な状況下でのみセキュリティ機能を無効にすべきであるという確固たるポリシーを設定する必要があります。問題の解決やアプリケーションの更新のために、機能を一時的に無効にしなければならない場合は、その記録を取る必要があります。必要な作業が完了した後、機能が完全に再有効化されていることを確認する必要があります。

業務を効率化するためにセキュリティ機能を恒久的に無効にしなければならない場合は、影響を受けるデータに他の保護機能を提供し、デフォルトの保護機能がない場合でもハッカーがアクセスできないようにする必要があります。必要な保護機能が無効化されている場合、攻撃者が鍵のかかっていないドアを見つけ、その状況を悪用するのは時間の問題です。

より多くのことを学び、自分自身に挑戦する。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守るための方法を紹介しています。

この記事を読んで、この脆弱性を見つけて修正する準備はできましたか?Secure Code Warrior プラットフォーム上のIaC のゲーム化されたセキュリティチャレンジに挑戦して、サイバーセキュリティのスキルを磨き、最新の状態にしましょう。

このシリーズでは、Infrastructure as Codeの脆弱性のトップ8を毎週紹介しています。

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

攻撃者は常に、簡単に利用できる脆弱性を最初に見つけようとし、スクリプトを使って一般的な弱点を洗い出すこともあります。これは、泥棒が通りにあるすべての車をチェックして、鍵のかかっていないドアがないかどうかを確認するのと同じことで、窓を壊すよりもずっと簡単なことです。

ご興味がおありですか?

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。

デモを予約する
シェアする
著者
マティアス・マドゥ博士
2020年5月04日発行

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

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

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

シェアする

昨今のサイバーセキュリティに対する脅威は、どこにでもあり、絶え間なく続いています。私たちの生活がデジタル化されればされるほど、サイバー犯罪者にとっての脅威は大きくなります。また、プログラムが導入された後に、攻撃対象のあらゆる側面を把握して防御しようとすることは、ほとんど不可能になっています。

このような症状を軽減するためのアプローチがありますが、その1つがInfrastructure as Code(IaC)のコンセプトを採用した賢明な組織です。もちろん、どのような開発でも、セキュリティ上の落とし穴があることは言うまでもありません。開発者は、アプリケーションをホストするための重要なインフラを生成するコードを作成しているため、プロセスのあらゆる段階でセキュリティを意識することが重要です。

では、クラウドサーバ環境に慣れていない開発者は、どのようにしてスキルアップし、ノウハウを学び、セキュリティ意識を高めて構築に臨めばよいのでしょうか。ここでは、IaCの一般的な脆弱性に取り組むため、「Coders Conquer Security」シリーズを作成しました。ここからの数回のブログでは、開発者が組織内でコードとしての安全なインフラを展開するためのステップに焦点を当てます。

さあ、始めましょう。

アメリカの旧西部には、山賊に襲われるのではないかと疑心暗鬼になっていた男の寓話がある。そのために彼は、頑丈な玄関ドアを設置したり、窓をすべて塞いだり、手の届くところにたくさんの銃を置いたりと、あらゆる種類のセキュリティに投資しました。それでも、ある夜、寝ている間に横のドアの鍵をかけ忘れて強盗に入られてしまった。窃盗団は、セキュリティの不備を見つけて、すぐにその状況を利用したのです。

インフラのセキュリティ機能が無効化されていることは、それとよく似ています。ネットワークに強力なセキュリティインフラがあったとしても、その要素が無効化されていては意味がありません。

飛び込む前に課題を提示します。

上のリンクをクリックすると、ゲーム性のあるトレーニングプラットフォームに移動し、今すぐ無効化されたセキュリティ機能の脆弱性の解消に挑戦することができます。(注意してください。しかし、ドロップダウンメニューを使えば、Docker、CloudFormation、Terraform、Ansibleから選ぶことができます)。)

あなたはどうでしたか?まだまだ課題があるという方は、ぜひ読んでみてください。

セキュリティ機能は、さまざまな理由で無効になることがあります。アプリケーションやフレームワークによっては、デフォルトで無効になっていて、機能を開始するためにはまずオンにする必要があります。また、管理者が特定のタスクをより簡単に実行できるように、特定のセキュリティ機能を無効にしている可能性もあります(例:AWSのS3バケットを公開する)。作業終了後、管理者は無効にした機能を再び有効にすることを忘れてしまうかもしれません。また、今後の作業を容易にするために、無効にしたままにしておくこともあるでしょう。

無効化されたセキュリティ機能が危険な理由

1つ以上の無効なセキュリティ機能を持つことは、いくつかの理由でよくありません。一つは、そのセキュリティ機能は、既知のエクスプロイト、脅威、または脆弱性から保護するためにインフラストラクチャリソースに搭載されています。それが無効になっていると、リソースを保護することができません。

攻撃者は常に、簡単に利用できる脆弱性を最初に見つけようとし、スクリプトを使って一般的な弱点を洗い出すこともあります。これは、泥棒が通りにあるすべての車をチェックして、鍵のかかっていないドアがないかどうかを確認するのと同じで、窓を破壊するよりもずっと簡単なことです。ハッカーは、一般的なセキュリティの防御策が不発であることに驚くかもしれません。しかし、そうなれば、それを悪用するのに時間はかからないでしょう。

第二に、優れたセキュリティを導入しておきながら、それを無効にしてしまうと、誤ったセキュリティ意識が生まれます。管理者は、誰かがその防御機能を無効にしたことを知らなければ、一般的な脅威から守られていると思うかもしれません。

無効化されたセキュリティ機能を攻撃者がどのように利用するかの例として、AWS S3のセキュリティ機能であるパブリックアクセスのブロックを考えてみましょう。Amazon S3のブロックパブリックアクセスを使えば、アカウント管理者やバケット所有者は、Amazon S3リソースへのパブリックアクセスを制限するための集中管理を簡単に設定することができます。しかし、S3バケットへのアクセス時に問題に遭遇した管理者の中には、できるだけ早くタスクを完了させるために、バケットを公開することを決める人もいます。もしそのセキュリティ機能を有効にするのを忘れてしまうと、攻撃者はそのS3バケットに保存されている情報に完全にアクセスすることができ、情報の漏洩だけでなく、データ転送料による余分なコストが発生してしまいます。

実際のコードを比較してみましょう。以下のCloudFormation snippetsをご覧ください。

ヴァルネラブル。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

確保。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

セキュリティ機能の無効化を防ぐ

無効にしたセキュリティ機能が組織に悪影響を与えないようにするには、ポリシーと実践の問題があります。非常に特殊な状況下でのみセキュリティ機能を無効にすべきであるという確固たるポリシーを設定する必要があります。問題の解決やアプリケーションの更新のために、機能を一時的に無効にしなければならない場合は、その記録を取る必要があります。必要な作業が完了した後、機能が完全に再有効化されていることを確認する必要があります。

業務を効率化するためにセキュリティ機能を恒久的に無効にしなければならない場合は、影響を受けるデータに他の保護機能を提供し、デフォルトの保護機能がない場合でもハッカーがアクセスできないようにする必要があります。必要な保護機能が無効化されている場合、攻撃者が鍵のかかっていないドアを見つけ、その状況を悪用するのは時間の問題です。

より多くのことを学び、自分自身に挑戦する。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守るための方法を紹介しています。

この記事を読んで、この脆弱性を見つけて修正する準備はできましたか?Secure Code Warrior プラットフォーム上のIaC のゲーム化されたセキュリティチャレンジに挑戦して、サイバーセキュリティのスキルを磨き、最新の状態にしましょう。

このシリーズでは、Infrastructure as Codeの脆弱性のトップ8を毎週紹介しています。

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

以下のフォームに記入し、レポートをダウンロードしてください。

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

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

昨今のサイバーセキュリティに対する脅威は、どこにでもあり、絶え間なく続いています。私たちの生活がデジタル化されればされるほど、サイバー犯罪者にとっての脅威は大きくなります。また、プログラムが導入された後に、攻撃対象のあらゆる側面を把握して防御しようとすることは、ほとんど不可能になっています。

このような症状を軽減するためのアプローチがありますが、その1つがInfrastructure as Code(IaC)のコンセプトを採用した賢明な組織です。もちろん、どのような開発でも、セキュリティ上の落とし穴があることは言うまでもありません。開発者は、アプリケーションをホストするための重要なインフラを生成するコードを作成しているため、プロセスのあらゆる段階でセキュリティを意識することが重要です。

では、クラウドサーバ環境に慣れていない開発者は、どのようにしてスキルアップし、ノウハウを学び、セキュリティ意識を高めて構築に臨めばよいのでしょうか。ここでは、IaCの一般的な脆弱性に取り組むため、「Coders Conquer Security」シリーズを作成しました。ここからの数回のブログでは、開発者が組織内でコードとしての安全なインフラを展開するためのステップに焦点を当てます。

さあ、始めましょう。

アメリカの旧西部には、山賊に襲われるのではないかと疑心暗鬼になっていた男の寓話がある。そのために彼は、頑丈な玄関ドアを設置したり、窓をすべて塞いだり、手の届くところにたくさんの銃を置いたりと、あらゆる種類のセキュリティに投資しました。それでも、ある夜、寝ている間に横のドアの鍵をかけ忘れて強盗に入られてしまった。窃盗団は、セキュリティの不備を見つけて、すぐにその状況を利用したのです。

インフラのセキュリティ機能が無効化されていることは、それとよく似ています。ネットワークに強力なセキュリティインフラがあったとしても、その要素が無効化されていては意味がありません。

飛び込む前に課題を提示します。

上のリンクをクリックすると、ゲーム性のあるトレーニングプラットフォームに移動し、今すぐ無効化されたセキュリティ機能の脆弱性の解消に挑戦することができます。(注意してください。しかし、ドロップダウンメニューを使えば、Docker、CloudFormation、Terraform、Ansibleから選ぶことができます)。)

あなたはどうでしたか?まだまだ課題があるという方は、ぜひ読んでみてください。

セキュリティ機能は、さまざまな理由で無効になることがあります。アプリケーションやフレームワークによっては、デフォルトで無効になっていて、機能を開始するためにはまずオンにする必要があります。また、管理者が特定のタスクをより簡単に実行できるように、特定のセキュリティ機能を無効にしている可能性もあります(例:AWSのS3バケットを公開する)。作業終了後、管理者は無効にした機能を再び有効にすることを忘れてしまうかもしれません。また、今後の作業を容易にするために、無効にしたままにしておくこともあるでしょう。

無効化されたセキュリティ機能が危険な理由

1つ以上の無効なセキュリティ機能を持つことは、いくつかの理由でよくありません。一つは、そのセキュリティ機能は、既知のエクスプロイト、脅威、または脆弱性から保護するためにインフラストラクチャリソースに搭載されています。それが無効になっていると、リソースを保護することができません。

攻撃者は常に、簡単に利用できる脆弱性を最初に見つけようとし、スクリプトを使って一般的な弱点を洗い出すこともあります。これは、泥棒が通りにあるすべての車をチェックして、鍵のかかっていないドアがないかどうかを確認するのと同じで、窓を破壊するよりもずっと簡単なことです。ハッカーは、一般的なセキュリティの防御策が不発であることに驚くかもしれません。しかし、そうなれば、それを悪用するのに時間はかからないでしょう。

第二に、優れたセキュリティを導入しておきながら、それを無効にしてしまうと、誤ったセキュリティ意識が生まれます。管理者は、誰かがその防御機能を無効にしたことを知らなければ、一般的な脅威から守られていると思うかもしれません。

無効化されたセキュリティ機能を攻撃者がどのように利用するかの例として、AWS S3のセキュリティ機能であるパブリックアクセスのブロックを考えてみましょう。Amazon S3のブロックパブリックアクセスを使えば、アカウント管理者やバケット所有者は、Amazon S3リソースへのパブリックアクセスを制限するための集中管理を簡単に設定することができます。しかし、S3バケットへのアクセス時に問題に遭遇した管理者の中には、できるだけ早くタスクを完了させるために、バケットを公開することを決める人もいます。もしそのセキュリティ機能を有効にするのを忘れてしまうと、攻撃者はそのS3バケットに保存されている情報に完全にアクセスすることができ、情報の漏洩だけでなく、データ転送料による余分なコストが発生してしまいます。

実際のコードを比較してみましょう。以下のCloudFormation snippetsをご覧ください。

ヴァルネラブル。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

確保。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

セキュリティ機能の無効化を防ぐ

無効にしたセキュリティ機能が組織に悪影響を与えないようにするには、ポリシーと実践の問題があります。非常に特殊な状況下でのみセキュリティ機能を無効にすべきであるという確固たるポリシーを設定する必要があります。問題の解決やアプリケーションの更新のために、機能を一時的に無効にしなければならない場合は、その記録を取る必要があります。必要な作業が完了した後、機能が完全に再有効化されていることを確認する必要があります。

業務を効率化するためにセキュリティ機能を恒久的に無効にしなければならない場合は、影響を受けるデータに他の保護機能を提供し、デフォルトの保護機能がない場合でもハッカーがアクセスできないようにする必要があります。必要な保護機能が無効化されている場合、攻撃者が鍵のかかっていないドアを見つけ、その状況を悪用するのは時間の問題です。

より多くのことを学び、自分自身に挑戦する。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守るための方法を紹介しています。

この記事を読んで、この脆弱性を見つけて修正する準備はできましたか?Secure Code Warrior プラットフォーム上のIaC のゲーム化されたセキュリティチャレンジに挑戦して、サイバーセキュリティのスキルを磨き、最新の状態にしましょう。

このシリーズでは、Infrastructure as Codeの脆弱性のトップ8を毎週紹介しています。

リソースにアクセス

以下のリンクをクリックし、この資料のPDFをダウンロードしてください。

Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。

レポートを見るデモを予約する
PDFをダウンロード
リソースを見る
シェアする
ご興味がおありですか?

シェアする
著者
マティアス・マドゥ博士
2020年5月04日発行

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

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

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

シェアする

昨今のサイバーセキュリティに対する脅威は、どこにでもあり、絶え間なく続いています。私たちの生活がデジタル化されればされるほど、サイバー犯罪者にとっての脅威は大きくなります。また、プログラムが導入された後に、攻撃対象のあらゆる側面を把握して防御しようとすることは、ほとんど不可能になっています。

このような症状を軽減するためのアプローチがありますが、その1つがInfrastructure as Code(IaC)のコンセプトを採用した賢明な組織です。もちろん、どのような開発でも、セキュリティ上の落とし穴があることは言うまでもありません。開発者は、アプリケーションをホストするための重要なインフラを生成するコードを作成しているため、プロセスのあらゆる段階でセキュリティを意識することが重要です。

では、クラウドサーバ環境に慣れていない開発者は、どのようにしてスキルアップし、ノウハウを学び、セキュリティ意識を高めて構築に臨めばよいのでしょうか。ここでは、IaCの一般的な脆弱性に取り組むため、「Coders Conquer Security」シリーズを作成しました。ここからの数回のブログでは、開発者が組織内でコードとしての安全なインフラを展開するためのステップに焦点を当てます。

さあ、始めましょう。

アメリカの旧西部には、山賊に襲われるのではないかと疑心暗鬼になっていた男の寓話がある。そのために彼は、頑丈な玄関ドアを設置したり、窓をすべて塞いだり、手の届くところにたくさんの銃を置いたりと、あらゆる種類のセキュリティに投資しました。それでも、ある夜、寝ている間に横のドアの鍵をかけ忘れて強盗に入られてしまった。窃盗団は、セキュリティの不備を見つけて、すぐにその状況を利用したのです。

インフラのセキュリティ機能が無効化されていることは、それとよく似ています。ネットワークに強力なセキュリティインフラがあったとしても、その要素が無効化されていては意味がありません。

飛び込む前に課題を提示します。

上のリンクをクリックすると、ゲーム性のあるトレーニングプラットフォームに移動し、今すぐ無効化されたセキュリティ機能の脆弱性の解消に挑戦することができます。(注意してください。しかし、ドロップダウンメニューを使えば、Docker、CloudFormation、Terraform、Ansibleから選ぶことができます)。)

あなたはどうでしたか?まだまだ課題があるという方は、ぜひ読んでみてください。

セキュリティ機能は、さまざまな理由で無効になることがあります。アプリケーションやフレームワークによっては、デフォルトで無効になっていて、機能を開始するためにはまずオンにする必要があります。また、管理者が特定のタスクをより簡単に実行できるように、特定のセキュリティ機能を無効にしている可能性もあります(例:AWSのS3バケットを公開する)。作業終了後、管理者は無効にした機能を再び有効にすることを忘れてしまうかもしれません。また、今後の作業を容易にするために、無効にしたままにしておくこともあるでしょう。

無効化されたセキュリティ機能が危険な理由

1つ以上の無効なセキュリティ機能を持つことは、いくつかの理由でよくありません。一つは、そのセキュリティ機能は、既知のエクスプロイト、脅威、または脆弱性から保護するためにインフラストラクチャリソースに搭載されています。それが無効になっていると、リソースを保護することができません。

攻撃者は常に、簡単に利用できる脆弱性を最初に見つけようとし、スクリプトを使って一般的な弱点を洗い出すこともあります。これは、泥棒が通りにあるすべての車をチェックして、鍵のかかっていないドアがないかどうかを確認するのと同じで、窓を破壊するよりもずっと簡単なことです。ハッカーは、一般的なセキュリティの防御策が不発であることに驚くかもしれません。しかし、そうなれば、それを悪用するのに時間はかからないでしょう。

第二に、優れたセキュリティを導入しておきながら、それを無効にしてしまうと、誤ったセキュリティ意識が生まれます。管理者は、誰かがその防御機能を無効にしたことを知らなければ、一般的な脅威から守られていると思うかもしれません。

無効化されたセキュリティ機能を攻撃者がどのように利用するかの例として、AWS S3のセキュリティ機能であるパブリックアクセスのブロックを考えてみましょう。Amazon S3のブロックパブリックアクセスを使えば、アカウント管理者やバケット所有者は、Amazon S3リソースへのパブリックアクセスを制限するための集中管理を簡単に設定することができます。しかし、S3バケットへのアクセス時に問題に遭遇した管理者の中には、できるだけ早くタスクを完了させるために、バケットを公開することを決める人もいます。もしそのセキュリティ機能を有効にするのを忘れてしまうと、攻撃者はそのS3バケットに保存されている情報に完全にアクセスすることができ、情報の漏洩だけでなく、データ転送料による余分なコストが発生してしまいます。

実際のコードを比較してみましょう。以下のCloudFormation snippetsをご覧ください。

ヴァルネラブル。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

確保。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

セキュリティ機能の無効化を防ぐ

無効にしたセキュリティ機能が組織に悪影響を与えないようにするには、ポリシーと実践の問題があります。非常に特殊な状況下でのみセキュリティ機能を無効にすべきであるという確固たるポリシーを設定する必要があります。問題の解決やアプリケーションの更新のために、機能を一時的に無効にしなければならない場合は、その記録を取る必要があります。必要な作業が完了した後、機能が完全に再有効化されていることを確認する必要があります。

業務を効率化するためにセキュリティ機能を恒久的に無効にしなければならない場合は、影響を受けるデータに他の保護機能を提供し、デフォルトの保護機能がない場合でもハッカーがアクセスできないようにする必要があります。必要な保護機能が無効化されている場合、攻撃者が鍵のかかっていないドアを見つけ、その状況を悪用するのは時間の問題です。

より多くのことを学び、自分自身に挑戦する。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守るための方法を紹介しています。

この記事を読んで、この脆弱性を見つけて修正する準備はできましたか?Secure Code Warrior プラットフォーム上のIaC のゲーム化されたセキュリティチャレンジに挑戦して、サイバーセキュリティのスキルを磨き、最新の状態にしましょう。

このシリーズでは、Infrastructure as Codeの脆弱性のトップ8を毎週紹介しています。

目次

PDFをダウンロード
リソースを見る
ご興味がおありですか?

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。

デモを予約するダウンロード
シェアする
リソース・ハブ

始めるためのリソース

その他の記事
リソース・ハブ

始めるためのリソース

その他の記事