2021.07.20

Dockerセキュリティベストプラクティストップ20：究極ガイド #aqua #コンテナ #セキュリティ #ベストプラクティス

172

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは「Aqua Security」社の技術ブログで2021年6月30日に公開された「 Top 20 Docker Security Best Practices: Ultimate Guide 」の日本語翻訳です。

Dockerセキュリティベストプラクティストップ20：究極ガイド

Docker は今やコンテナの代名詞となりましたが、コンテナの開発と実行のプロセスをより効率的にするために、様々なコンテナツールやプラットフォームが登場しました。Docker のセキュリティに関する多くは、他のツールで構築されたコンテナベースのアプリケーションを保護するためにも適用されます。私たちは、より安全なコンテナを構築するのに役立つ、20 の必須の Docker セキュリティのベストプラクティスを包括的なハンズオンガイドにまとめました。

この記事では、Docker セキュリティのベストプラクティスについて学びます。

また、Docker CIS Security Benchmarkのセキュリティベストプラクティスをまとめたおまけセクションも追加したので、安全な構成のベストプラクティスも知ることができます。

Dockerとホストの設定

1. ホストとDockerのバージョンを最新の状態に保つ

Docker Engine と Docker を実行しているホスト OS の両方にパッチを当てることは、既知のさまざまな脆弱性を防ぐために不可欠です。これらの脆弱性の多くはコンテナエスケープにつながる可能性があります。

カーネルはコンテナとホストで共有されているため、攻撃者がコンテナ上で実行することに成功した場合のカーネルエクスプロイトは、ホストに直接影響を与えます。例えば、カーネルの悪用に成功すると、攻撃者は非特権コンテナを抜け出し、ホストへの root アクセスが可能になります。

2. Dockerデーモンのソケットを露呈しない

Docker デーモンのソケットは、Docker API との通信を容易にする UNIX ネットワークソケットです。デフォルトでは、このソケットは root ユーザが所有しています。他のユーザがこのソケットにアクセスした場合、ホストに対する root アクセスと同等のパーミッションが与えられます。

デーモンソケットをネットワークインターフェースにバインドすることで、Docker コンテナをリモートで利用できるようにすることも可能ですのでご注意ください。このオプションは、特に運用中のコンテナ環境で使用する場合は、注意して有効にする必要があります。

この問題を回避するには、以下のベストプラクティスに従ってください。

認証をサポートする、暗号化された Docker の HTTPS ソケットを使用している場合を除き、デーモンソケットをリモート接続可能にしないでください。
Docker コンテナイメージに -v /var/run/docker.sock://var/run/docker.sockのようなオプションをつけて実行しないでください。これは、コンテナ内でソケットを公開することになります。

3. rootlessモードでDockerを起動

Docker には、Docker のデーモンやコンテナを非 root ユーザとして実行できる「rootless」モードが用意されています。これを利用することで、ノードやクラスターの root アクセスを攻撃者に許すようなデーモンやコンテナの脆弱性があっても、そのリスクを軽減することができます。

rootless モードは、ユーザネームスペース内で Docker のデーモンやコンテナを実行します。これは userns-remap モードと似ていますが、それとは異なり、rootless モードはデフォルトで root 権限なしでデーモンとコンテナを実行します。

Docker を rootless モードで動かすには以下のステップを実行します。

root で Docker をインストールします。手順はこちらから参照ください。
以下のコマンドで、ホストの起動時にデーモンを起動します。
systemctl --user enable docker
sudo loginctl enable-linger $(whoami)
ここでは、Docker context を使ってコンテナを rootless で実行する方法を紹介します。
docker context use rootless
docker run -d -p 8080:80 nginx

4. 特権コンテナの利用を避ける

Docker には特権モードがあり、コンテナをローカルマシンの root として実行できます。特権モードでコンテナを実行すると、そのホストの機能(以下を含む)が提供されます。

すべてのデバイスへの root アクセス
AppArmor や SELinux などの Linux セキュリティモジュールを改ざんする能力
ホストのカーネル機能を使用して Docker プラットフォームの新しいインスタンスをインストールし、Docker 内で Docker を実行する能力

特権コンテナは、コンテナが侵害された場合、攻撃者が簡単に特権を昇格できるという大きなセキュリティリスクをもたらします。そのため、本番環境で特権コンテナを使用することはお勧めできません。どのような環境でも使用しないでください。

コンテナが特権モードで動作しているかどうかを確認するには、次のコマンドを使用します(コンテナが特権モードであれば true を返し、そうでなければエラーメッセージを返します)。

ddocker inspect --format='{{.HostConfig.Privileged}}' [container_id]

5. コンテナリソースを制限する

コンテナが侵害されると、攻撃者は基礎となるホストリソースを利用して、悪意あるアクティビティを実行する可能性があります。Docker のメモリと CPU の使用制限を設定し、リソースを多用するコンテナに対する侵害の影響を最小限に抑えます。

Docker では、デフォルトでコンテナがホスト上のすべての RAM および CPU リソースに、アクセスできるようになっています。リソースクォータを設定し、コンテナが使用できるリソースを制限することは、セキュリティ上の理由から各コンテナが適切なリソースを使用し、ホスト上で実行されている他のサービスを妨害しないようにするためにも重要です。

6. コンテナネットワークを分離する

Docker コンテナは、ホスト上のネットワークインターフェースを介して外部と通信するために、ネットワーク層を必要とします。デフォルトのブリッジネットワークはすべての Docker ホストに存在し、別のネットワークを指定しない限り、新しいコンテナは自動的にブリッジネットワークに接続します。

デフォルトのブリッジネットワークには依存しないことを強くお勧めします。カスタムブリッジネットワークを使用して、どのコンテナ同士が通信できるか制御したり、コンテナ名から IP アドレスへの自動 DNS 解決を有効にしたりします。必要な数のネットワークを作成し、各コンテナがどのネットワークに接続するかを決めることができます。

絶対に必要な場合にのみコンテナ同士が接続できるようにし、機密性の高いコンテナを一般向けのネットワークに接続することは避けてください。

Docker は、独自のブリッジネットワーク、オーバーレイネットワーク、または macvlan ネットワークを作成できるネットワークドライバーを提供しています。さらにコントロールが必要な場合は、Docker ネットワークプラグインを作成できます。

7. コンテナの分離性向上

運用チームは、コンテナを実行するために、最適な環境を構築する必要があります。コンテナエスケープからホストOSのカーネルを保護し、コンテナ間の相互影響を防ぐことが理想的です。

コンテナは、空間の分離やリソースの制限が施された Linux プロセスで、共有の OS カーネル上で動作します。コンテナを保護することは、Linux 上で動作するあらゆるプロセスを保護することとまったく同じです。以下の Linux セキュリティ機能を必要に応じて使用できます。

Linux ネームスペース
ネームスペースは、Linux プロセスが独自の独立したグローバルリソースにアクセスしているように見せるためのものです。ネームスペースは、あたかもコンテナ内で独自の OS 上で動作しているかのような抽象化を提供します。ネームスペースは、コンテナアイソレーションの基礎となります。
SELinux
Red Hat Linux ディストリビューションでは、SELinux が追加のセキュリティ層を提供し、コンテナとホスト、コンテナと他コンテナを隔離します。管理者は、ユーザ・アプリケーション・プロセス・ファイルに対して強制的なアクセス制御を適用できます。SELinux は、ネームスペースの抽象化を突破しようとする攻撃者を阻止するための第二の防衛線となります。
AppArmor
Debian Linux ディストリビューションでは、AppArmor は Linux カーネルの拡張機能で、プログラムがアクセスできるシステムリソースを制限できます。AppArmor は、アクセスコントロール属性を特定のプログラムにバインドし、ブート時にカーネルが読み込むセキュリティプロファイルで制御されます。
cgroups
CPU・メモリ・ディスクI/O・ネットワークなど、プロセスグループのリソース使用を制限・分離します。cgroups を使用することで、コンテナのリソースが同じホスト上の他のコンテナに使用されるのを防ぎ、同時に攻撃者が疑似デバイスを作成するのを阻止できます。
capabilities
Linux では、コンテナを含めたあらゆるプロセスの権限を制限できます。Linux にはプロセスごとに有効にできる特権利用を有効/無効にできる「capabilities」が用意されています。コンテナを実行する場合、通常、コンテナ化されたアプリケーションに影響を与えることなく、多数の capabilities に対する特権を拒否できます。
Seccomp
Linux カーネルのセキュアコンピューティングモード(seccomp)では、プロセスをセキュアモードに移行させることができます。このモードでは、一部の安全なシステムコールの実行のみが許可されます。コンテナに seccomp プロファイルを設定することで、危殆化に対する防御レベルが1つ向上します。

8. ファイルシステムとボリュームを読み取り専用に設定する

シンプルで効果的なセキュリティ対策は、コンテナを読み取り専用のファイルシステムで実行することです。これにより、コンテナ上にマルウェアを展開したり、設定を変更したりするような悪意のある行為を防ぐことができます。

~~以下のコードでは、Docker コンテナを読み取り専用に設定しています。~~

本家ブログの画像消失に伴い削除しました。2023-05-25

9. 完全なライフサイクル管理

クラウドネイティブセキュリティでは、構築からワークロード、インフラに至るまで、アプリケーションライフサイクルのあらゆる段階でセキュリティ管理と緩和技術が必要です。以下のベスト・プラクティスに従ってください。

脆弱性スキャンを実施し、開発ライフサイクルのすべての段階でクリーンなコードを確保する。
実行時にデプロイされるコードが悪意のないことを確認するため、本番環境へのデプロイ前に、コード実行時に解析できるサンドボックス環境を使用する。
コンテナの不変性を確保する。
インシデント対応プロセスを構築し、攻撃を受けた際の迅速な対応を確保する。
自動パッチを適用する。
迅速なトラブルシューティングとコンプライアンス報告のために、堅牢な監査とフォレンジックを導入する。

10. コンテナ内でのシステムコールの制限

コンテナでは、任意のシステムコールを許可するか拒否するかを選択できます。コンテナの実行に、すべてのシステムコールが必要なわけではありません。

この点を考慮してコンテナを監視し、実行されたすべてのシステムコールのリストを取得し、それらのコールを明示的に許可し、他のコールを許可しないようにできます。コンテナのコンポーネントが使用している特定のシステムコールや、それらのコールが基礎となる OS でどのように命名されているかが分からない可能性があるため、設定は実行時のコンテナの観察に基づいて行うことが重要です。

コンテナイメージを守る

11. コンテナイメージのスキャンと検証

Docker コンテナイメージは、特にパブリックレジストリから取得したものであれば、使用前に脆弱性をテストする必要があります。イメージの任意のコンポーネントの脆弱性は、そのイメージから作成したすべてのコンテナに存在することを覚えておいてください。ベースイメージを使用して新しいイメージを作成した場合、ベースイメージの脆弱性は新しいイメージにも及ぶことになります。

コンテナイメージスキャンとは、イメージの内容や構成を分析して、セキュリティ上の問題や設定ミス、脆弱性を検出するプロセスです。

セキュリティ上の脆弱性を持つソフトウェアを含むコンテナイメージは、コンテナの実行時に攻撃を受ける可能性があります。CI パイプラインからイメージを構築する場合は、ビルドを実行する前にスキャンする必要があります。重大度の閾値を超えた脆弱性を持つコンテナイメージは、ビルドに失敗するはずです。安全でないイメージは、本番システムからアクセス可能なコンテナレジストリに push すべきではありません。

オープンソースや独自の仕様を備えたイメージスキャナーは数多くあります。包括的なソリューションは、OS、コンテナ内で実行されている特定のライブラリ、およびそれらの依存関係の両方をスキャンできます。イメージ内のコンポーネントが使用している言語を、スキャナーがサポートしていることを確認しましょう。

ほとんどのイメージスキャナーは、複数の CVE(Common Vulnerability and Exposure)データベースを使用し、それらの CVE がコンテナイメージ内に存在するかどうかをテストします。また、セキュリティのベストプラクティスや設定ミスがないか、コンテナイメージをテストできるツールもあります。

12. 最小限のベースイメージを使用

Docker イメージは、一般的に「ベースイメージ」の上に構築されます。これは、イメージを1から設定する必要がないため便利ですが、セキュリティ上の懸念が生じます。ベースイメージには、目的に応じて実際には必要のないコンポーネントを使用できます。よくある例としては、ベースイメージに Debian stretch のフルディストリビューションを使用し、特定のプロジェクトでは OS のライブラリや機能をあまり必要としない場合があります。

イメージにコンポーネントを追加すると、攻撃対象が広がることを忘れないでください。自分の目的に合ったベースイメージを慎重に選び、必要であれば自分で最小限のベースイメージを作るようにしてください。

13. 機密情報をDockerイメージに保存しない

Docker イメージでは、認証情報、トークン、SSHキー、TLS 証明書、データベース名、接続文字列など、通常の操作のためにセンシティブなデータを必要とすることがよくあります。また、コンテナ内で動作するアプリケーションが機密データを生成・保存する場合もあります。機密情報は決して Dockerfile にハードコードしてはいけません。この情報は Docker コンテナにコピーされ、削除しようとしても、中間コンテナ層にキャッシュされる可能性があります。

Kubernetes や Docker Swarm のようなコンテナオーケストレーターは、この問題を解決できるシークレット管理機能を提供しています。イメージやソースコードに保存することなく、実行時にコンテナが必要とする機密データをシークレットで管理できます。

14. マルチステージビルドを使用する

コンテナ化されたアプリケーションを一貫した方法で構築するには、マルチステージビルドを使用するのが一般的です。これには、運用面とセキュリティ面でのメリットがあります。

マルチステージビルドでは、最終成果物のコンパイルまたは生成に必要なすべてのツールを含む中間コンテナを作成します。最終段階では、生成されたアーティファクトのみが最終イメージにコピーされ、開発の依存関係や一時的なビルドファイルは含まれません。

適切に設計されたマルチステージビルドでは、最終イメージに必要な最小限のバイナリファイルと依存関係のみが含まれ、ビルドツールや中間ファイルは含まれません。これにより、攻撃対象を大幅に減らすことができます。

さらに、マルチステージビルドでは、コンテナイメージに含まれるファイルやアーティファクトをより細かく管理できるため、攻撃者や内部関係者が悪意のあるアーティファクトや未テストのアーティファクトを勝手に追加することが難しくなります。

15. コンテナレジストリを守る

コンテナレジストリは、ボタンをクリックするだけでコンテナイメージをダウンロードしたり、開発やテストのワークフローの一部として自動的にダウンロードしたりできる非常に便利なものです。

しかし、この利便性にはセキュリティ上のリスクが伴います。レジストリからダウンロードしたイメージが、信頼できるものであるという保証はありません。意図せずにセキュリティ上の脆弱性が含まれていたり、攻撃者が意図的に危険なイメージへ置き換えた可能性もあります。

解決策としては、自社のファイアウォールの内側に配置されたプライベートレジストリを使用することで、改竄のリスクを軽減できます。また、レジストリを保護するために、RBAC(Role Based Access Control)を使用して、レジストリにイメージをアップロードしたりダウンロードしたりできるユーザを制限してください。

チーム全体に開放されたアクセス権を与えることは避けてください。これは操作を簡単にする一方で、チームのメンバーが攻撃を受けて、コンテナイメージに不要なアーティファクトを混入させるリスクを高めることになります。

16. 不変性を担保するためにイメージタグを管理する

タグは、Docker イメージのバージョンを管理するためによく使われます。例えば latest タグは、イメージの最新バージョンであることを示すために使用されます。しかし、タグは変更可能であるため、複数のイメージが最新のタグを持つ可能性があり、自動ビルドにおいて混乱や一貫性のない動作を引き起こします。

タグを不変のものとし、その後のコンテナイメージの変更に影響をうけないためには、主に 3 つの戦略があります。

より具体的なタグを命名する-コンテナイメージに複数のタグがある場合、ビルドプロセスは最も多くの情報(例えば、バージョンと OS の両方)を含むタグを命名する必要があります。
コンテナイメージのローカルコピーを保持する-たとえば、プライベートレジストリにコンテナイメージを保存し、タグがローカルコピーのものと同じであることを確認します。
コンテナイメージへの署名-Docker にはコンテンツトラストの仕組みがあり、秘密鍵を使ってコンテナイメージに署名できます。これにより、コンテナイメージとそのタグが変更されていないことを保証します。

コンテナを監視する

17. コンテナのアクティビティを監視する

可視性と監視は、Docker コンテナの円滑な運用とセキュリティに不可欠です。コンテナ化された環境は動的であり、環境で何が実行されているかを理解し、異常を特定して対応するためには綿密な監視が必要です。

各コンテナイメージは、複数の実行中のインスタンスを持つことができます。新しいイメージやバージョンがデプロイされる速度が速いため、問題はコンテナやアプリケーション全体に素早く伝播します。そのため、問題を早期に特定し、ソースから修復することが重要です。たとえば、不具合のあるイメージを特定して修正し、そのイメージを使用しているすべてのコンテナを再構築することが挙げられます。

以下のコンポーネントの可視性と監視を実現するためのツールとプラクティスを導入しましょう。

Dockerホスト
コンテナエンジン
マスターノード(ex.Kubernetes)
コンテナ化されたミドルウェアとネットワーク
実行中のコンテナ

大規模な環境では、クラウドネイティブな専用の監視ツールだけが実現可能となります。

18. コンテナランタイムを守る

クラウドネイティブスタックの中心にあるのはワークロードであり、ハッカーにとっては常に貴重な資産です。進行中の攻撃を阻止する能力は最も重要ですが、ゼロデイ脆弱性への攻撃が発生したとき、あるいは発生する前に効果的に阻止できる組織はほとんどありません。

Docker コンテナ向けに提供されているランタイムセキュリティでは、一度コンテナ化されるとコンテナの不変性が担保され、悪意のある行為はブロックされます。理想的には、最小限のオーバーヘッドと迅速な応答時間でこれを実現することです。

不変性を担保できるランタイムセキュリティを導入して、進行中の攻撃を阻止し、ゼロデイ攻撃を防ぎます。さらに、自動化された脆弱性パッチと管理を使用して、更なるランタイムセキュリティを行います。

19. トラブルシュートに必要なデータはコンテナの外に保持する

保守作業のたびにチームがコンテナに SSH でログインする必要があると、セキュリティ上のリスクが生じます。コンテナに直接アクセスする必要のないメンテナンス方法を設計する必要があります。

SSH アクセスを制限するための良い方法は、コンテナの外でログを利用できるようにすることです。この方法では、管理者はログインせずにコンテナのトラブルシューティングを行うことができます。そうすれば、コンテナへ直接アクセスすることなく、既存のコンテナを停止して新しいコンテナをデプロイできます。

20. コンテナイメージ管理にラベルを使用する

コンテナのラベル付けは一般的に行われており、イメージ、デプロイメント、Docker コンテナ、ボリューム、ネットワークなどのオブジェクトに適用されます。

ラベルは、ライセンス情報、ソース、作成者の名前、コンテナとプロジェクトやコンポーネントとの関係など、コンテナに情報を追加するために使用します。また、保護されたデータを含むコンテナのラベル付けなど、コンプライアンス上の目的でコンテナとそのコンテンツを分類するためにも使用できます。

ラベルは、コンテナ化された環境の整理やワークフローの自動化によく使われます。しかし、ワークフローがラベルに依存している場合、ラベルを適用する際にエラーが発生すると、重大な結果を招く可能性があります。この問題に対処するには、ラベル付けプロセスを可能な限り自動化し、ラベルの割り当てや変更を許可するユーザや役割を慎重に管理します。

おまけ：Docker CIS Security Benchmark：より安全なDocker設定

CIS ベンチマークは、サイバーセキュリティの専門家やエキスパートによって開発された普遍的なセキュリティのベストプラクティスです。各 CIS ベンチマークは、安全なシステム構成を作成するためのガイドラインを提供しています。以下の表は、CIS Docker Community Edition Benchmark からの推奨事項をまとめたもので、安全なdocker構成を設定する方法を明記しています。

CIS Docker Benchmark の全文はこちらからご参照ください。

ホスト設定

コンテナ用に独立したパーティションを作成
コンテナホストの強化
定期的な Docker ソフトウェアのアップデート
Docker デーモンのアクセス権限を賢く管理
Docker ファイルのディレクトリを設定
すべての Docker デーモンの活動を監査

Dockerデーモン設定

デフォルトのブリッジコンテナ間のネットワークトラフィックを制限し、コンテナからの新しい権限へのアクセスを制限
ユーザーネームスペースのサポートを有効にして、追加の Docker クライアントコマンドの承認、ライブリストア、デフォルトの cgroup の使用を提供
レガシーなレジストリ操作と Userland Proxy を無効化
Docker による iptables の変更を許可することでネットワークの誤設定を回避し、デプロイ時に実験的な機能を使用しないよう制限
Docker デーモンの TLS 認証、および収集ログとリモートログを設定
ロギングレベルを「info」に設定し、適切なデフォルトの ulimit を設定
安全ではないレジストリとストレージドライバーを使用しない
コンテナの基本デバイスサイズを適用し、デーモン全体のカスタム SECCOMP プロファイルを適用して呼び出しを制限

コンテナイメージとDockerfileの作成

コンテナのユーザを作成
コンテナが信頼できるイメージのみを使用
コンテナに不要なパッケージがインストールされないようにする
スキャンや再構築の際にセキュリティパッチを含める
Docker のコンテンツトラストを有効にする
コンテナイメージに HEALTHCHECK の指示を追加
イメージから setuid と setgid のパーミッションを削除
Dockerfile で ADD の代わりに COPY を使用
検証済みのパッケージのみをインストール
Dockerfile の中でアップデート命令を 1 行または単独で使用しない
Dockerfile にシークレットを保存しない

コンテナランタイム

コンテナが追加の権限を取得することを制限し、Linux Kernel Capabilities を制限
AppArmor Profile を有効にする
ランタイム中の特権付きコンテナの使用、コンテナ内での ssh の実行、コンテナ内での特権付きポートのマッピングを避ける
ホストシステムの機密ディレクトリがコンテナにマウントされていないこと、コンテナのルートファイルシステムが読み取り専用でマウントされていること、Docker ソケットがすべてのコンテナ内にマウントされていないこと
コンテナに適切な CPU 優先度を設定し、「障害発生時」のコンテナ再起動ポリシーを「5」に設定し、コンテナ上で必要なポートのみを公開
必要に応じて SELinux セキュリティオプションを適用し、ランタイムにデフォルトの ulimit を上書き
ホストのネットワークネームスペース、ホストのプロセスネームスペース、ホストの IPC ネームスペース、マウントモード、ホストの UTS ネームスペース、ホストのユーザーネームスペースを共有しない
コンテナのメモリ使用量を制限し、受信するコンテナのトラフィックを特定のホストインターフェースにバインドする
ホストデバイスをコンテナに直接公開しない、デフォルトの SECCOMP プロファイルを無効にしない、docker exec コマンドに特権オプションとユーザオプションを使用しない、Docker のデフォルトブリッジ docker0 を使用しない
cgroup の使用状況を確認し、PID の cgroup 制限を使用すること、実行時にコンテナの健全性を確認すること、常に最新バージョンのイメージで docker コマンドを更新すること

Dockerセキュリティ運用

無計画なコンテナイメージの作成、コンテナのデプロイを避ける。

Docker Swarm 設定

必要な場合のみ swarm モードを有効にする
最小限の数のマネージャーノードを作成する
Swarm Service を特定のホストインターフェースにバインドする
異なるオーバーレイネットワークノードでのコンテナのデータ交換を暗号化する
Docker のシークレット管理コマンドで Swarm クラスタのシークレットを管理する
自動ロックモードでの swarm manager の実行
swarm manager の自動ロックキーを定期的にローテーションする
必要に応じてノードや CA の証明書をローテーション
マネジメントプレーントラフィックとデータプレーントラフィックの分離

Aquaによる全体的なDockerセキュリティ

Aqua は、クラウドネイティブ、サーバーレス、Docker などのコンテナ技術を保護するプラットフォームを提供します。Docker Enterprise Edition または Community Edition を実行するアプリケーションにエンドツーエンドのセキュリティを提供し、イメージのビルド前からコンテナランタイム、ファイアウォール、監査、コンプライアンスまで継続的デリバリと DevOps パイプラインの全ライフサイクルを通じて保護します。

継続的イメージスキャン

Aqua はイメージをスキャンし、マルウェア、脆弱性、埋め込まれたシークレット情報、構成上の問題、OSS のライセンスなどを確認します。例えば、どのイメージを Docker ホスト上で実行できるかなどのポリシーを策定できます。継続的に更新されるデータストリームに基づく Aqua の脆弱性データベースは、複数のソースから集約され、最新のデータのみが使用されるように統合されており、精度を高め、誤検知の発生を抑止します。

また Aqua では、パッケージの脆弱性についてコンテナイメージをスキャンできる「Trivy」というオープンソースツールを提供しています。Trivy は、Aqua の商用スキャナと同じ脆弱性データベースを使用しています。主な違いは、Trivy が Dockerfile 内に作成されたビルドステップに従って実行される点です。

コンテナランタイムセキュリティ

Aqua は実行時に Docker アプリケーションを保護します。コンテナの不変性を確保し、実行中のコンテナへの変更を禁止するとともに、機械学習されたカスタム SECCOMP プロファイルによりコンテナをホストから隔離します。また、機械学習によって作成されたプロファイルを用いて、ファイル、実行ファイル、OS リソースの最小権限を確保し、コンテナファイアウォールでネットワーク接続を管理します。

Aqua は以下のように Docker のセキュリティをさらに強化します。

イベントロギングとレポーティング-アクセスアクティビティ、Docker コマンド、イベント、コンテナアクティビティ、システムイベント、シークレットアクティビティの監査をします。
CIS 認証ベンチマークテスト-定期的なレポートとテスト、または Aqua OSS ツールを用いて、Docker および Kubernetes の CIS ベンチマークに対するノード構成を評価します。
グローバルコンプライアンステンプレート-あらかじめ定義されたコンプライアンスポリシーは、HIPPA、CIS、PCI、NIST などのセキュリティ基準を満たします。
フルユーザアカウンタビリティ-詳細なユーザアカウンタビリティーとスーパーユーザ・パーミッションを監視します。
Thin OS ホストコンプライアンス-ホストをスキャンして、マルウェア、脆弱性、ログインアクティビティを検出し、ホストに保存されているイメージを特定します。
コンプライアンスの実行制御-コンプライアンスチェックにクリアしたイメージとワークロードのみが環境内で実行できます。

コンテナファイアウォール

Aqua のコンテナファイアウォールはネットワーク接続を可視化し、アプリケーションサービスに基づいてルールを策定して、正当な接続を自動的にマッピングできます。Swarm や Kubernetes のクラスター内/クラスター間でも、ホワイトリストに登録された接続のみが許可されます。

シークレット管理

認証情報をシークレットとしてソースコードに残してはいけません。Aqua は実行時にシークレットを暗号化してコンテナへ安全な転送を行い、ディスク上で永続化せずメモリ上に配置するため、関連するコンテナにしか見えません。Aqua のソリューションを、CyberArk、Hashicorp、AWS KMS、Azure Vault など現在使用しているエンタープライズのサービスと統合できます。コンテナを再起動することなくシークレットの取り消し、更新、ローテーションを行うことができます。