Coders Conquer Security Infrastructure as Codeシリーズ：無効化されたセキュリティ機能

今日のサイバーセキュリティに対する脅威は、いたるところに存在し、容赦がありません。私たちの生活のあらゆる側面がデジタル化されるにつれ、サイバー犯罪者にとっての標的としての価値は高まっています。守るべきコードはあまりに多く、個人データはあまりに価値があるからです。それに、プログラムがデプロイされた後、攻撃対象領域のあらゆる側面を把握し、防御し続けることは、ほぼ不可能になっています。

こうした状況を緩和するアプローチはいくつか存在します。その一つが、賢明な組織が採用している「Infrastructure as Code（IaC）」という概念です。もちろん、どのような開発にも言えることですが、注意すべきセキュリティ上の落とし穴は存在します。アプリケーションをホストするための重要なインフラを生成するコードを開発者が扱っている以上、プロセスのあらゆる段階でセキュリティ意識を持つことが不可欠です。

では、クラウドサーバー環境に不慣れな開発者は、どのようにスキルを磨き、コツを学び、セキュリティ意識を高めて構築に取り組めばよいのでしょうか？私たちは、一般的なIaCの脆弱性に対処するための「Coders Conquer Security」シリーズを新たに作成しました。今後のブログ記事では、開発者である皆さんが、自身の組織で安全なInfrastructure as Codeをデプロイし始めるために取れるステップに焦点を当てていきます。

それでは、始めましょう。

アメリカの西部開拓時代に、こんな寓話があります。ある男が、強盗に襲われて家財を奪われることを恐れるあまり、強固な玄関ドアを取り付け、すべての窓に板を打ち付け、すぐに手に取れる場所に銃をたくさん置くなど、あらゆるセキュリティ対策を講じました。しかしある夜、彼は寝ている間に強盗に入られてしまいました。裏口の鍵をかけ忘れていたからです。強盗は、無効化されていたセキュリティの隙を簡単に見つけ、その状況を即座に悪用したのです。

インフラストラクチャのセキュリティ機能を無効にしておくことは、まさにこれと同じです。ネットワークに強力なセキュリティ基盤が整っていたとしても、一部の要素が無効化されていれば、ほとんど意味をなしません。

本題に入る前に、一つ課題を出しましょう。

上記のリンクから、私たちのゲーミフィケーションを取り入れたトレーニングプラットフォームにアクセスし、無効化されたセキュリティ機能の脆弱性を克服する演習に挑戦してみてください。（注意：最初はKubernetesで開きますが、ドロップダウンメニューからDocker、CloudFormation、Terraform、Ansibleを選択することも可能です）。

結果はどうでしたか？もし苦戦したなら、この先を読み進めてください。

セキュリティ機能が無効化される理由はさまざまです。一部のアプリケーションやフレームワークでは、デフォルトで無効になっており、機能させるために手動で有効化する必要がある場合があります。また、管理者が特定のタスクを遂行する際、頻繁に警告やブロックを受けるのを避けるために、意図的にセキュリティ機能を無効化することもあります（例：AWS S3バケットをパブリックにするなど）。作業が終わった後、無効化した機能を元に戻すのを忘れてしまうのです。あるいは、将来の作業を楽にするために、あえてオフのままにしておくケースもあります。

なぜ無効化されたセキュリティ機能が危険なのか

セキュリティ機能が一つでも無効になっていると、いくつかの理由で危険です。第一に、セキュリティ機能は、既知の悪用、脅威、脆弱性から保護するためにインフラリソースに組み込まれているからです。それが無効であれば、リソースを保護することはできません。

攻撃者は常に、悪用しやすい脆弱性を真っ先に探そうとします。スクリプトを使って一般的な弱点を次々とチェックすることさえあります。これは、泥棒が通りに並んだ車を片っ端から確認し、鍵が開いている車を探すようなものです。窓を割るよりもはるかに簡単だからです。ハッカーは、一般的なセキュリティ対策が機能していないのを見つけて驚くかもしれませんが、一度見つけてしまえば、それを悪用するのに時間はかかりません。

第二に、適切なセキュリティ対策を講じているつもりで、実際には無効化されている場合、誤った安心感を生んでしまいます。管理者は、誰かが防御機能を無効にしたことを知らなければ、一般的な脅威から守られていると思い込んでしまうのです。

攻撃者が無効化されたセキュリティ機能をどのように悪用するか、AWS S3の「パブリックアクセスブロック」機能を例に考えてみましょう。Amazon S3のパブリックアクセスブロックを使用すると、アカウント管理者やバケット所有者は、Amazon S3リソースへのパブリックアクセスを制限する一元的な制御を簡単に設定できます。しかし、S3バケットへのアクセスで問題に直面した管理者が、タスクを迅速に完了させるために、一時的にバケットをパブリックにしてしまうことがあります。もしそのセキュリティ機能を有効に戻し忘れると、攻撃者はそのS3バケットに保存されている情報に完全にアクセスできるようになります。これにより、情報漏洩が発生するだけでなく、データ転送量に応じた追加コストが発生する可能性もあります。

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

脆弱なコード:

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を毎週紹介しています。来週の更新もぜひチェックしてください！