コーダーはセキュリティインフラをコードの集合体として征服する：セキュリティ機能が無効化される

現代において、サイバーセキュリティへの脅威は遍在し、絶え間なく存在している。私たちの生活のあらゆる側面がデジタル化されるにつれ、サイバー犯罪者にとっての利害関係は高まる一方だ：保護すべきコードが多すぎる上、個人データは過度に価値が高い。そして、プログラム展開後の攻撃対象領域のあらゆる側面を追跡し防御しようとすることは、ほぼ不可能となっている。

特定のアプローチによってこれらの症状の一部を緩和することが可能であり、その一つは、先見の明のある組織がインフラストラクチャ・アズ・コード（IaC）の概念を採用する際に明らかになる。もちろん、あらゆる開発と同様に、克服すべきセキュリティ上の落とし穴が存在する。 開発者がアプリケーションをホストする重要なインフラを生成するコードに取り組む以上、プロセスの各段階でセキュリティ意識が不可欠です。

では、クラウドサーバー環境で開発を始めたばかりの開発者は、どのようにスキルを向上させ、ノウハウを学び、セキュリティ意識を高めてバージョン管理に取り組めばよいのでしょうか？私たちは、IaCの一般的な脆弱性に対処するため、新たなシリーズ「Coders Conquer Security」を立ち上げました。今後のブログでは、開発者として自組織内でコードとしてのインフラストラクチャを安全に展開し始めるために、あなたが取れる対策に焦点を当てていきます。

さあ、行こう。

アメリカの西部開拓時代の寓話に、強盗に襲われて財産を奪われるのではないかと偏執的なほど恐れる男の話がある。 その不安を補うため、彼はあらゆる防犯対策に投資した。頑丈な玄関ドアの設置、全ての窓の施錠、そして多数の武器を手元に置くことなどだ。しかしある夜、彼が眠っている間に強盗に遭ってしまった。なぜなら、彼は横のドアの鍵をかけるのを忘れていたのだ。強盗たちは単に防犯が手抜かりだと気づき、素早くその隙を突いたのである。

インフラのセキュリティ機能を無効化することは、まさにこのようなものです。たとえネットワークに堅牢なセキュリティ基盤が整っていても、一部の機能が無効化されていれば意味がありません。

本題に入る前に、一つ挑戦を申し上げましょう：

上記のリンクをクリックすると、ゲーミフィケーションを採用したトレーニングプラットフォームにリダイレクトされます。そこで、無効化されたセキュリティ脆弱性を今すぐ中和する挑戦が可能です。（ご注意：Kubernetesで起動しますが、ドロップダウンメニューからDocker、CloudFormation、Terraform、Ansibleを選択できます）。

どうやってやりくりしたの？まだやるべき仕事があるなら、以下を読んでください：

セキュリティ機能は様々な理由で無効化される場合があります。特定のアプリケーションやフレームワークでは、デフォルトで無効化されており、動作を開始するにはまず有効化する必要があります。また、管理者が特定のセキュリティ機能を無効化している可能性もあります。これにより、常に警告やブロックを受けずに特定のタスクを容易に実行できるようになります（例：AWS S3コンパートメントを公開設定にする）。 作業終了後、無効化した機能を再有効化するのを忘れる場合があります。また、将来の作業効率化のために無効状態を維持することを選択する場合もあります。

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

セキュリティ機能の1つまたは複数を無効化することは、いくつかの理由から望ましくありません。第一に、セキュリティ機能は既知の悪用、脅威、脆弱性から保護するためにインフラストラクチャのリソースに組み込まれています。無効化すると、リソースを保護できなくなります。

攻撃者は常に、まず簡単に悪用できる脆弱性を探そうとし、一般的な弱点を修正するスクリプトさえ使用することがあります。 これは、窓ガラスを割るよりもはるかに簡単な方法として、通りにある全ての車のドアがロックされていないかを確認する泥棒のようなものです。ハッカーは、一般的なセキュリティ防御が無効になっていることに驚くかもしれません。しかし、それが発生した場合、彼らがそれを悪用するのに長くはかからないでしょう。

第二に、適切なセキュリティ対策を実装した後にそれを無効化することは、偽りの安心感を生み出します。管理者は、誰かがこれらの防御機能を無効化したことを知らなければ、一般的な脅威から保護されていると誤解する可能性があります。

セキュリティ機能を無効化した場合に攻撃者が悪用する可能性の一例として、AWS S3の公開アクセスブロック機能を考えてみましょう。Amazon S3の公開アクセスをブロックすることで、アカウント管理者やバケット所有者は、Amazon S3リソースへの公開アクセスを制限する集中管理型制御を容易に設定できます。 しかし、S3バケットへのアクセスに問題が生じた一部の管理者は、作業を迅速に完了させるため、一時的に公開設定に変更することがあります。このセキュリティ機能を有効化するのを忘れた場合、攻撃者は当該S3バケットに保存された情報へ完全なアクセス権を取得します。これにより情報漏洩が発生するだけでなく、データ転送料金による追加コストも発生します。

実際のコードの比較：以下のCloudFormationの抜粋をご覧ください：

脆弱な：

企業アカウント :
タイプ : AWS : :S3 : :Bucket
プロパティ :
パブリックアクセスブロック設定 :
BlockPublicACLS : false
BlockPublicPolicy : false
IgnorepublicACLS : false
RestrictPublicBuckets : false
バージョン管理の設定 :
状態 : 有効
バケットの暗号化 :
サーバーサイド暗号化の設定 :
- デフォルトのサーバーサイド暗号化 :
SSEアルゴリズム : 「AES256」

安全：

企業アカウント :
タイプ : AWS : :S3 : :Bucket
プロパティ :
パブリックアクセスブロック設定 :
BlockPublicACLS : true
BlockPublicPolicy : true
Ignorepublicacls : true
RestrictPublicBuckets : true
バージョン管理の設定 :
状態 : 有効
バケットの暗号化 :
サーバーサイド暗号化の設定 :
- デフォルトのサーバーサイド暗号化 :
SSEアルゴリズム : 「AES256」

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

セキュリティ機能を無効化することで組織に悪影響が及ぶのを防ぐことは、実践面だけでなくポリシー面でも重要です。セキュリティ機能は無条件に無効化すべきではなく、極めて限定的な状況下でのみ無効化を認めるという厳格なポリシーを策定すべきです。問題解決やアプリケーション更新のため一時的に機能を無効化する必要が生じた事例は、すべて記録に残す必要があります。 必要な作業が完了したら、機能が完全に再有効化されたことを確認する必要があります。

セキュリティ機能を運用効率化のために完全に無効化する場合、デフォルトの保護が失われた状態でもハッカーがアクセスできないよう、対象データに対して代替保護策を講じる必要がある。必須の保護機能が解除されれば、攻撃者がこの無防備な隙間を発見し悪用するのは時間の問題である。

もっと学び、挑戦しよう：

Secure Code Warrior を参照してください Secure Code Warrior のブログページを参照し、この脆弱性について、また他のセキュリティ侵害や脆弱性による被害から組織や顧客を守る方法について詳しく学びましょう。

この記事を読んだ今、この脆弱性を見つけて修正する準備はできていますか？Secure Code Warrior でIaCのゲーミフィケーション型セキュリティチャレンジに挑戦し Secure Code Warrior サイバーセキュリティのスキルを磨き、最新の状態に保ちましょう。

この週次シリーズでは、インフラストラクチャ・アズ・コードに関連する8つの主要な脆弱性について解説します。詳細は来週もお見逃しなく！