このブログ投稿は、Docker の専門知識が認められた経験豊富な専門家である Docker Captains によって書かれました。自分の仕事や率いる組織内でDockerを使用した直接の実際の経験を共有しています。Docker キャプテンは、Docker のエコシステムを前進させる技術専門家であり、情熱的なコミュニティ ビルダーです。彼らは積極的な貢献者および支持者として、Dockerの知識を共有し、Docker製品の形成を支援します。Docker Captain になる方法または連絡する方法の詳細については、 Docker CaptainsのWebサイト.
セキュリティは、世界中のあらゆる種類の組織にとって最大の関心事です。これはテクノロジーのすべての時代を経てきました。最初はメインフレーム、次にサーバー、次にクラウドがあり、そのすべてにパブリックとプライベートのバリエーションがありました。進化するたびに、セキュリティ上の懸念は増大し、コンプライアンスが難しくなりました。
分散システムの世界に進出すると、セキュリティチームは環境の急速な進化に対処しなければなりませんでした。新しいプログラミング言語、新しいライブラリ、新しいパッケージ、新しいイメージ、新しいすべて。
セキュリティを正しく処理するには、セキュリティエンジニアは、 開発者エクスペリエンス が影響を受けないことを常に保証する、強力で適切に設計されたセキュリティアーキテクチャを必要としていました。そこでDockerの出番です!
コンテナセキュリティの基本
コンテナのセキュリティは 、さまざまなトピックをカバーしています。この分野は非常に広いため、このテーマについてのみ書かれた本全体があります。しかし、エンタープライズ環境に入るときは、優先順位を付ける必要があるいくつかの特定のトピックに絞り込むことができます。
- 成果 物
- コード
- ビルドファイル(例:Dockerfile)の作成
- 脆弱性管理
- 文化/プロセス
これらのトピックについてもう少し詳しく見てみましょう。
成果 物
これが安全な環境への第一歩です。エンジニアが信頼できるリソースを利用できるようにする。
セキュリティチームと開発者の間の摩擦を減らすために、セキュリティエンジニアは、開発者が安全なリソースを利用できるようにして、開発者がイメージ、ライブラリ、依存関係全般を取得して、システムで使用し始めることができるようにする必要があります。
Docker Hardened Images (この記事のいくつかのセクションで説明します) は、それに役立ちます。
エンタープライズ環境では、通常、承認されたアーティファクトの一元化されたリポジトリが表示されます。これにより、チームはリソースと環境で使用されるコンポーネントを管理できると同時に、開発者は何かが必要なときにどこを見ればよいかを知ることができます。
コード
すべては、書かれたコードから始まります。問題のあるコードを本番環境にプッシュすることは、最初は悪くないように思えるかもしれませんが、長期的には多くの問題を引き起こします。
セキュリティでは、あらゆる表面を考慮する必要があります。世界で最も安全なビルドファイルを作成し、資産を管理するための最も堅牢なプロセスを持ち、優れたIAM(Identity and Access Management)ワークフローを持つことができますが、コードが適切に書かれていないと露出します。
開発者の専門知識だけに頼るだけでなく、問題が指摘されたときに問題を特定して軽減するためのガードレールを作成する必要があります。これにより、実行されたすべての作業に対して 2 番目の保護層が適用されます。ツールを導入すると、開発者が最初は気づかない間違いが発生する可能性があります。
十分な訓練を受けた開発者と、コードが通過するCI/CDパイプラインに適切なコントロールがあれば、悪いコードを本番環境に送信していないことがわかり、夜も安心できます。
パイプラインに適用できるコントロールをいくつか示します。
- SCA(ソフトウェア構成分析)
- SAST/DAST/IAST
- シークレットスキャン
- 依存関係スキャン
ビルドファイル
SDLC(ソフトウェア開発ライフサイクル)の初期に、エンジニアはビルドファイル(通常は Dockerfile)を作成して、アプリケーションの依存関係をダウンロードし、それをコンテナに変換する必要があります。
ビルドファイルの作成は、一連の手順で済むため、簡単です。何か (パッケージやライブラリなど) をダウンロードし、インストールし、フォルダーまたはファイルを作成し、次のコンポーネントをダウンロードしてインストールし、すべての手順が完了するまで繰り返します。ただし、通常は既定値と設定で機能しますが、すべてのセキュリティ ガードレールとベスト プラクティスが既定で適用されているわけではありません。そのため、本番環境にプッシュされるものには注意が必要です。
ビルド ファイルをコーディングするときは、次のことを確認することが重要です。
- そこにハードコードされた秘密はないということ。
- コンテナがrootとして実行するように構成されていないこと - これにより、攻撃者が権限を昇格させ、ホストにアクセスできる可能性があります。
- コンテナーにコピーされた機密ファイル (証明書や資格情報など) がないこと。
最初にこれらの手順を実行し、強力に開始することで、SDLC の残りの部分が最小限に露出されることが保証されます。
脆弱性管理
現在、私たちはコードやエンジニアに提供するアーティファクトから離れ始めています。
脆弱性はすべてに見つかります。テクノロジー、プロセス、あらゆることについて。エンジンを動かし続けるには、優れた脆弱性管理が必要です。
企業は、外出先で脆弱性を特定し、修正し、必要なときにそれを受け入れるための、十分に確立されたプロセスを持つ必要があります。通常、リスクを取る価値があるのか、それとも先に進む前に修正する必要があるのかを理解するために、社内でフレームワークが開発されています。
これらの脆弱性は、新しいものでも、既知のものでもかまいません。これらは、コードで使用されるライブラリ、システムで使用されるコンテナーイメージ、および環境で使用されるソリューションのバージョンに存在する可能性があります。
彼らはどこにでもいます!必ずそれらを特定し、登録したままにしておき、必要に応じて修正してください。
文化/プロセス
企業のセキュリティにリスクをもたらすのはテクノロジーだけではありません。不十分なトレーニングを受けたエンジニアや不適切なプロセスも、企業のセキュリティ構造に対する真の脅威となります。
プロセスに欠陥があると、間違ったコードが本番環境にプッシュされる可能性があります。または、システムで使用されるコンテナーイメージの不正なバージョンかもしれません。
人、プロセス、テクノロジーがどのように関連しているかを視野に入れると、ライブラリの脆弱性評価の問題がクラスター全体を侵害する可能性がある理由を理解できるかもしれません。または、ユーザーに誤って帰属したロールが、クラウド環境全体の整合性に重大なリスクをもたらす理由。
これらは誇張された例ですが、テクノロジーでは、たとえ目に見えなくても、すべてがつながっていることを示すのに役立ちます。
だからこそ、プロセスは非常に重要です。堅実なプロセスとは、利害関係者を喜ばせるのではなく、設定された結果に焦点を当てることを意味します。フィードバックを考慮し、前進するにつれて調整を行うことは重要ですが、全会一致の合意が得られない場合でも、これらのプロセスに確実に従う必要があります。
プロセスを成功させるには、次のことを行う必要があります。
- ガードレールの設計
- 手順の実装
- チームのトレーニング
- 繰り返す
それがチームを効果的に有効にする唯一の方法です。
Dockerがエンジニアと企業を保護する方法
Dockerは、しばらくの間、ソフトウェアエンジニアとセキュリティチームの味方でした。分散システムの成功を可能にするだけでなく、開発者がアプリケーションを作成してコンテナ化する方法を改善することでもあります。
Dockerプラットフォームが進化するにつれて、顧客と同様にセキュリティが最優先事項として考慮されるようになりました。
現在、開発者はプラットフォームのさまざまな部分でさまざまな Docker セキュリティ ソリューションにアクセスできます。
ドッカースカウト
Docker Scout は、コンテナ イメージとそのレイヤーを分析して既知の脆弱性を検出するために Docker によって作成されたサービスです。一般に知られているCVEをチェックし、イメージの脆弱性に関する情報をユーザーに提供します。また、軽減策を支援するために、Docker Scoutはユーザーに「修正可能な」値を提供し、その脆弱性を修正できるかどうかを宣言します。
これは、セキュリティチームがイメージが組織にもたらすリスクを認識し、その量のリスクを負うことができるかどうかを判断できるため、企業環境に入ると非常に役立ちます。
私たちは皆、CLIが大好きですが、GUI(グラフィカルユーザーインターフェイス)があると役立つ場合があります。Dockerは開発者が何を好むかを知っているため、両方のプラットフォームにScoutがあります。開発者はこれを使用してイメージをスキャンし、ターミナルで簡単な概要を確認したり、Docker Desktop が提供する機能を楽しんで、見つかったイメージの脆弱性に関するリンクと説明を含む完全なレポートを表示したりできます。
Docker Scoutターミナルレポート
Docker Scout Desktop レポート
これらのレポートをユーザーに提供することで、ユーザーはさまざまなライブラリやパッケージをアプリケーションに採用する際により賢明な選択をすることができ、セキュリティチームと緊密に連携して、そのテクノロジーが安全に使用できるかどうかについてより迅速なフィードバックを提供することもできます。
Docker Hardened Images
現在、エンジニアや企業に安全で推奨されるリソースを提供することに重点を置いている Docker は、アプリケーションの構築を開始するためのほぼゼロの CVE イメージと最適化されたリソースのリストである Docker Hardened Images (DHI) を最近発表しました。
大規模な組織では、安全なイメージと依存関係を保存するためのプライベートコンテナレジストリを持つのが一般的ですが、利用可能なリソースは広範な検査と監査を経ているため、DHIはセキュリティチームにとってより安全な出発点を提供します。
Docker Hardened Images レポート
DHIは、企業だけでなく、独立したオープンソースソフトウェア開発者にとっても非常に役立つリソースです。Docker でバックアップされたイメージにより、インターネットとクラウドがより安全になり、企業は顧客向けに信頼できるプラットフォームを構築できるようになります。
エンジニアの観点から見ると、Docker Hardened Images の真の価値は、Docker に対する信頼と、このセキュリティ対応ソリューションがもたらす価値です。イメージセキュリティの管理は、最後まで行わなければならない場合、困難です。画像をすぐに使えるようにしておくのは難しく、開発者が毎日新しいバージョンを要求していると、難易度はさらに高まります。Hardened Images を使用することで、エンドユーザー (開発者とエンジニア) に利用可能な最も一般的なソリューションの最新バージョンを提供し、セキュリティ チームの負担を軽減することができます。
最終的な考え
セキュリティにはさまざまな方法でアプローチできますが、重要なことは、セキュリティがエンジニアの速度を低下させることはできないということです。すべてをカバーし、特定されたすべてのギャップを満たしながら、開発者がコードを迅速に提供できるようにコントロールを設計する必要があります。
エンジニアがDockerで両方の長所を生かすことを保証します。
セキュリティ❤️ DevEx