InfoSec の皆さん、DevOps チームを保護するために何をしていますか?

DevOps、サーバーレスアプリケーション、コンテナは、開発者ツールボックスにおける最新の進歩のほんの一部に過ぎません。開発チームにとって、これは市場投入までの時間（TTM）の短縮を意味します。特にアジャイルチームにおいてはなおさらです。では、セキュリティ運用チームは、この急速な発展にセキュリティが追いつくために、どのように、そして何を行っているのでしょうか？多くの企業が開発チーム内にセキュリティエンジニアを組み込もうとしており、これは素晴らしい第一歩と言えるでしょう。しかし、ソースコード以外にも、組織を確実に保護するためには、複数のレイヤーを踏襲する必要があります。.

DevOps や DevSecOps は大きな前進ですが、多くの組織にとって DevOps の導入（および実装）は依然として困難です。たとえ組織が DevSecOps を導入したとしても、すべてのセキュリティチームが認識しておくべき重大な懸念事項が依然として存在します。.

組織の規模を問わず、小規模なテクノロジー系スタートアップからグローバル企業まで、迅速な導入は競争優位性を維持する鍵となります。セキュリティは、開発チームが業務を遂行するために必要な権限を提供する必要があります。開発者とセキュリティチームは、必要に応じてツールやライブラリなどをインストールできる必要があります。.

聞いたことがあるでしょう NPMが侵害されている ですよね？ アーチリナックス? パイソン? 組織内でこれを検出し防止するために、どのようなセキュリティ管理を実施していますか?

すべての環境を監視する

セキュリティチームは、上流のサードパーティ製パッケージの侵害から本番システムに至るまで、日々対処しなければならない数多くの懸念事項を抱えています。しかし、デプロイメント環境はどうでしょうか？QA環境はどうでしょうか？本番環境と同様に、QA環境も監視していますか？そうあるべきです。.

多くの場合（必ずしもベストプラクティスではありませんが）、開発環境やQA環境は、既知の良好な環境（本番環境など）の複製となります。つまり、この環境は 持っているかもしれない 生産 セキュリティチームが認識しておくべきデータです。これらの開発環境は、本番環境と同等または類似のセキュリティ対策を講じ、本番システムと同様に監視（およびログ記録）する必要があります。.

追加できるコントロールは他にも多数ありますが、重要なのは、チームがこれらの環境を正確に監視し、あらゆる環境に加えられた変更を可視化できるようにする必要があるということです。.

開発環境や QA 環境に非本番データがたくさん詰め込まれている場合でも、注意が必要なリスクが存在します。.

キー、トークン、CI/CD、おやおや！

開発者はCI/CD（継続的インテグレーションと継続的デリバリー）のビルド環境とデプロイ環境にアクセスできますか？ローカルまたはAWS/Azure/GCPなどの開発環境にアクセスできますか？

答えが「はい」の場合、開発者のアクティビティ（特にローカルシステム上）を綿密に監視する必要があります。危険なサイトにアクセスしたり、フィッシングメールに騙されたりするだけで、深刻な危険にさらされる可能性があります。.

開発者がクラウドベースのリソースにアクセスする場合、通常は認証情報やアクセスキー、シークレットキーを使ってこれらの環境にアクセスします。これらの情報はどこに保存されているでしょうか？そうです、ローカルシステムです。確認すべき場所を簡単にご紹介します。

AWS CLI: ls ~/.aws ~/.aws/credentials ~/.aws/config Azure CLI: $HOME/.azure (*nix & macOS) %USERPROFILE%\.azure (Windows)

開発者のマシン上のこれらの認証情報が侵害された場合、組織にとって壊滅的な被害をもたらす可能性があります。悪意のある攻撃者は、コンパイルされたバイナリやライブラリで検出されることなく、CI/CD環境を改変し、コードベースを改ざんする可能性があります。.

さらに、開発者が誤って秘密情報をリポジトリにコミットするのを防ぐ必要があります。これを検出する方法はいくつかありますが、1つは git-secrets AWS から。.

セキュリティ チームが、秘密がどこに保管され、どのように使用され、これらの資格情報の潜在的な悪用を監視または警告しない場合にどのような結果が生じるかを理解していることを確認します。.

コンテナ化

組織がコンテナ、サーバーレス、そしてInfrastructure as Code（IaaS）への移行を進める中で、情報セキュリティチームは開発チームと連携し、セキュリティチームが継続的に監視する社内コンテナリポジトリを構築する必要があります。新しいパッケージやライブラリが必要な場合は、開発チームのセキュリティエンジニアがコードをレビューしてから、マスターブランチにマージするようにしてください。さらに、コミットに残された潜在的な機密情報や、製品にインポートまたは使用されている脆弱なサードパーティライブラリを特定するために、リポジトリの自動スキャンを導入することも重要です。.

開発チーム + セキュリティ

あなたが開発チームに所属していると想像してみてください。他の部署の誰かがやって来て、あなたの仕事はひどい出来で、セキュリティホールだらけだと言ったとします。あなたはどう反応しますか？特に、自分のコードがかなり良いと思っているなら、おそらくあまり良い反応はしないでしょう。

開発チームとのこのようなやり取りは日常的に発生しており、この問題には従来とは異なるアプローチが必要です。だからこそ、開発チームにセキュリティエンジニアを配置する必要があるのです。セキュリティエンジニアは、セキュリティ上の問題を特定し、バックログ項目（チケット）を作成し、それらのバックログ項目に対応（コーディング）できる必要があります。このキーパーソンは、開発チームにおいて開発者であると同時にセキュリティスペシャリストでもあります。.

さて、チームメイトからフィードバックを受ける場面を想像してみてください。開発チームの他のメンバーはより理解を示し、直接コミュニケーションを取ることができるでしょう。開発者とセキュリティ担当者の間に長期的な関係を築くことも含まれるでしょう。慣れてくると、残りの開発者はチームメイトに余計な負担をかけたくなくなるでしょう。では、彼らは時間をかけて実装を検討するでしょうか、それとも立ち止まってじっくり考えるでしょうか？私はそう思います。.

さらに、このセキュリティ エンジニアは事実上のセキュリティ担当者であり、製品のセキュリティの処理方法 (認証、共有秘密、通信など) に影響を与える可能性のある初期設計の決定に関与する必要があるため、早い段階で製品マネージャー/オーナーおよびアーキテクトとの話し合いに参加させる必要があります。

まとめ

セキュリティ専門家は皆、多忙です。アラートは多すぎて、1日の時間は足りません。すべてのアラートに対応できないとしても、セキュリティオペレーションセンター（SOC）チームのメンバーは、組織のミッション、重要な資産の所在地、そして常に進化する脅威環境において何に注意すべきかを理解する必要があります。開発チームと協力することで、それぞれの組織を保護し、開発ライフサイクルにセキュリティを根付かせることができます。.