IaC スキャニング: 素晴らしい、見過ごされてきた学習の機会

コードとしてのインフラストラクチャ (IaC) について読むものはすべて、それがどのように機能するか、または構築したい方法で実際に構築されていることを確認したい理由に焦点を当てています。

これらは重要な領域です。 しかし、組織内でこのアプローチをどのように使用するかについて十分に考えているでしょうか?

As メリンダ・マークス ESG の企業レポートによると、「組織の 83% が IaC テンプレートの構成ミスの増加を経験している」と、テクノロジーの採用を続けています。

クラウド セキュリティ アライアンス (「クラウド コンピューティングに対する上位の脅威: Egregious Eleven") など、構成ミスは引き続きクラウドの最大のリスクです。

IaC がサポートされている 減らします
インフラストラクチャの作成を体系化し、チームが必要なものだけを構築できるようにするための厳密さとプロセスを追加することで、構成ミスを防ぎます。 チームの ~ 83% がそれを認識していない場合は、より深い問題が発生しています。

小規模なチームでは、DevOps 哲学の Dev と Ops の部分が一緒になっているチームでは、それは理にかなっています。 IaC を使用すると、これらの小規模なチームは同じ言語 (コード) を使用して、自分たちが行っていることすべてを説明できます。

これが、Terraform や AWS CloudFormation などのツールよりもさらに高レベルの抽象化が見られる理由です。 AWS CDK とのようなプロジェクト cdk8s. これらの高レベルの抽象化は、開発者にとってより快適です。

クラウド サービスの運用/SRE/プラットフォームの観点は、同じサービスの開発者の観点とは大きく異なります。 開発者はキューイング サービスを見て、そのインターフェイスに飛び込みます — 追加する単純なエンドポイントと読み取るエンドポイント? 売却。 これは簡単な統合です。

この運用上の観点は、エッジを見つけることを目的としています。 では、このキューが限界に達するのはいつでしょうか? パフォーマンスは一定ですか、それとも負荷がかかると急激に変化しますか?

はい、重複する懸念があります。 はい、これは単純化されたビューです。 しかし、その考えは成り立ちます。 IaC は多くの問題を解決しますが、チーム間の断絶を生み出し、増幅する可能性もあります。 さらに重要なことは、構築しようとしているものの意図と、構築したものの現実との間のギャップを浮き彫りにすることができるということです。

その結果、ここでセキュリティ上の懸念がエスカレートすることがよくあります。

ほとんどのツール (商用またはオープン ソース) は、インフラストラクチャ テンプレートの問題点を特定することに重点を置いています。 この
良い構造です。 作る この
悪いでしょう。 これらのツールは、継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの一部としてこれらの結果を生成することを目的としています。

それは素晴らしいスタートです。 しかし、それは同じ言語の問題を反映しています。

誰が話し、誰が聞いているのか?

IaC ツールで問題が浮き彫りになった場合、誰がそれに対処しますか? 開発チームの場合、これが問題として報告された理由を知るのに十分な情報がありますか? 運用チームの場合、問題の結果はレポートに示されていますか?

開発者の場合、IaC テストに合格するように構成を調整するだけで済むことがよくあります。

操作の場合、通常はテストが合格するかどうかの問題です。 そうであれば、次のタスクに進みます。 それはどちらのチームにとっても問題ではありません。 むしろ、期待と現実のギャップを強調しています。

必要なのはコンテキストです。 IaC セキュリティ ツールは、(できれば) 構築しようとしているものを可視化します。 目標は、問題を停止することです 彼らは生産に入ります。

今日の IaC セキュリティ ツールは、対処が必要な実際の問題を浮き彫りにしています。 これらのツールの出力を取得し、コードを担当するチームに固有の追加のコンテキストで強化することは、カスタム自動化の絶好の機会です。

これは、言語のギャップを埋めるのにも役立ちます。 ツールからの出力は基本的に第 XNUMX 言語であり、複雑にするためです。また、開発者または運用者のいずれかにとって意味のある方法で伝達する必要があります。 多くの場合、両方です。

たとえば、セキュリティ グループ ルールに説明がないというフラグがスキャンで検出された場合、それが問題になるのはなぜでしょうか? 「コンテキストの説明を追加してください」というアラートを受け取るだけでは、より良い構築には役立ちません。

このタイプのフラグは、クラウドで構築しているチームを教育する絶好の機会です。 セキュリティ グループ ルールはできるだけ具体的なものにする必要があるという説明を追加すると、悪意のある攻撃の機会が減ります。 強力なルールの例への参照を提供します。 意図を知らずにそれを呼び出すと、他のチームはセキュリティ確認の有効性をテストできません。

セキュリティは全員の責任であるため、開発者と運用の間の言語のギャップを認識することで、チームに洞察を提供する単純な自動化を追加するこのような機会が浮き彫りになります。 これは、彼らが構築しているものを改善するのに役立ち、その結果、より良いセキュリティ成果を推進します.

著者について

私は法医学者であり、講演者であり、技術アナリストでもあり、デジタル世界とそれが私たちに与える影響を理解する手助けをしようとしています. 毎日のユーザーにとって、私の仕事はデジタル世界の課題を説明するのに役立ちます. ソーシャル メディアの使用がプライバシーに与える影響はどれほど大きいでしょうか? 顔認識のような技術が私たちのコミュニティで使用され始めたとき、それは何を意味するのでしょうか? このような質問に答えるのに役立ちます。 テクノロジーを構築する人々のために、セキュリティとプライバシーのレンズを仕事に適用して、ユーザーが自分の情報と行動についてより明確な決定を下せるように支援します. プライバシーとセキュリティに関しては、混乱の山があります。 あってはならない。 セキュリティとプライバシーをわかりやすくします。