セキュリティに関する推奨事項

16 セキュリティに関する推奨事項

セキュリティに関する推奨事項とガイドラインに従って、インフラストラクチャとコンテナ化されたアプリケーションの安全性を確保します。

悪用を減らすために環境のインフラストラクチャ内のすべてのレベルでセキュリティ・ガイドラインに従ってください。環境内で使用されるコンポーネントごとにベスト・プラクティス・ガイドラインに従ってください。

コンテナ化では、同じホストで実行されているアプリケーション間のリソース分離が提供されますが、分離は完了せず、コンテナから分離したり、同じホストで実行されている他のコンテナに影響を与えるような方法でコンテナを利用したりできます。組織内に異なるテナンシがある場合、または同じインフラストラクチャを使用している顧客が異なる場合は、コンテナを異なるホストまたは異なる仮想マシンで実行して、より完全な分離を実現し、重大なデータ侵害の可能性を防ぐことが不可欠です。

ホスト

ホスト・カーネルおよびOSソフトウェアを定期的に更新します。

カーネルおよびOSソフトウェアのセキュリティ・パッチおよびバグ修正は、問題が解決されるとリリースされます。最新のソフトウェア更新でOSを最新の状態に保ちます。システムを最新のソフトウェア・チャネルまたはリポジトリにサブスクライブし、通常のDNF更新操作を実行します。 Kspliceを使用してシステム・ソフトウェアを最新の状態に保つことを検討してください。

最小限のOSを使用し、セキュリティのベスト・プラクティスに従っていることを確認します。

可能な場合は、最小限のOSインストールを使用し、次のドキュメントで説明されているセキュリティのベスト・プラクティスに従っていることを確認します。

最も重要なことは、同じシステムで実行されているサービスの数を減らすことです。理想的なのは、常駐する他のすべてのサービスをPodmanで管理されているコンテナ内に移動するか、それらを全体的に他のシステムに移動することです。これにより、コンテナが破損した場合に損傷を防ぐことができます。

安全のためにOSとカーネルを定期的に検査する

OSは、安全性と潜在的な脆弱性を定期的に検査していることに注意してください。

最適なセキュリティ機能セットを提供する成熟したシステム・コンポーネントを使用します。

セキュリティおよび機能に関する既知の問題がすべて解決されるように、カーネルなどのすべてのシステム・コンポーネントを最新の状態に保つことをお薦めします。 Unbreakable Enterprise Kernel (UEK)を使用している場合は、カーネル・ネームスペース、プライベート・ネットワーキング、制御グループなどのカーネルベースの機能が成熟し、信頼性が高く、厳密にテストされるように、Oracle Linuxリリースに使用可能な最新のUEK生成を使用することを検討してください。

Linuxセキュリティ・モジュールの使用

可能な場合は、ホスト上で適切なセキュリティ・モジュールを使用します。たとえば、強制モードでSELinuxを実行して、実行しているコンテナ・イメージからホストを保護します。また、ボリューム・マウントを使用する場合は、コンテナ間またはコンテナとホスト・システム間でSELinuxセキュリティ・コンテキストを共有する必要がある場合は、-zオプションの使用を検討してください。これは、コンテナがホストと同じSELinuxコンテキストで評価されるため、root以外のユーザーとしてコンテナを実行する場合に便利です。ボリュームを実行中コンテナのみに限定するには、-Zオプションを使用します。詳細は、「コンテナ・マウントの設定」を参照してください。

Podmanイメージ

イメージが検証済で信頼できるソースから取得されていることを確認します

Podmanイメージが、信頼できるレピュテーションがある認証されたソースから取得され、未変更のままデプロイされることを確認してください。例については、「署名付きイメージに対するPodmanの構成」を参照してください。

リモート・ソースからイメージをプルする場合は、接続が保護されており、プル・リクエストにHTTPSを使用していることを確認してください。セキュアでなく、TLSで保護されていないイメージ・レジストリは使用しないでください。

可能な場合は、キュレーションされた信頼できるイメージ・サプライヤのコレクションに基づいてPodmanイメージを使用します。

再現可能なイメージの作成

Containerfileを使用して新しいイメージを構築する場合は、セキュリティのためにベース・イメージとインストール済ソフトウェアを確認します。セキュリティの脆弱性を確認したベース・イメージとソフトウェアが新しいイメージで使用されるようにするには、次のようにします。

イメージのContainerfileにおいてベース・イメージに固定バージョンを指定します。
イメージのContainerfileのビルド・ステップにおいて、パッケージのプルに固定バージョンを指定します(なお、依存関係の依存関係は、引き続き信頼性の問題になるある可能性があります)。
ビルド・ステップでのパッケージのプルに信頼できる検証済のソースが使用されていることを確認します

イメージにインストールされているパッケージを最小化

新しいイメージ・ビルドには不要なパッケージをインストールしないでください。 Containerfileを確認して不要なインストール・ステップを削除し、イメージがその機能のみに限定されるようにします。

Podmanコンテナ

root以外のユーザーとしてコンテナを実行します。

Podmanでは、Podmanコンテナを実行するホスト・ユーザーとして、各コンテナが実行されます。ホスト・ユーザーは、rootユーザーまたはroot以外のユーザーです。ほとんどのセキュリティーのために、root以外のホストユーザーでコンテナを実行します。

メモリーおよびCPU使用率が制限されたコンテナの実行を検討します

メモリーおよびスワップメモリーの -mおよび --memory-swapオプション、およびCPUの -cオプションを使用して、コンテナメモリーおよびCPU使用量を制限することを検討してください。

コンテナ再起動の制限

制御できないコンテナに起因する潜在的なサービス拒否を防ぐには、コンテナの作成時または実行時に、--restart=on-failure:Nオプションを使用してコンテナの再起動を制限します。

コンテナ・リソース使用率の監視

Podmanは、メモリー使用量、CPU時間、I/Oおよびネットワーク使用率など、コンテナ・リソースの使用状況を監視する機能を備えています。コンテナのリソース使用率を調べてパフォーマンス、エラー検出および異常な動作を確認します。リソースの使用、疑わしいトラフィック、予期しないユーザー・アクティビティなど、異常なアクティビティがないかリアルタイムにリソース使用状況を監視できるツールの使用を検討してください。

コンテナ・ファイル・アクセスの制限

コンテナを作成して実行する場合は、--read-onlyフラグまたは-v host dir:container dir:roオプションを使用してコンテナ・ファイル・アクセスを制限します。コンテナ・アプリケーションが書き込むためのボリュームを明示的に作成し、これらのボリューム内のファイルへの変更を監視します。コンテナの書込みアクセス専用のボリュームにスプロールがないか確認し、定期的にクリーン・アップするようにします。次の例は、:roオプションを使用してホスト・フォルダまたはファイルがコンテナに対して読取り専用になるようにホスト・ディレクトリをマウントする方法を示しています。

podman run -v /host_directory_to_be_mounted:/target_container_directory:ro oraclelinux:9

前述の例では、host_directory_to_be_mountedはボリュームとしてマウントされるホスト・ディレクトリおよびファイルであり、target_container_directoryはホスト・ディレクトリがマウントされるコンテナ上のディレクトリです。

コンテナ実行時に機密のホスト・システム・ディレクトリをマウントしないでください。

/
/boot
/dev
/etc
/lib
/proc
/sys
/usr

コンテナの安全性を定期的に確認

コンテナの安全性チェックの自動化や、コンテナ内の変更の監視に役立つツールの使用を検討してください。

イメージおよびコンテナのスプロールを回避し、セキュリティの検査を回避した古い未使用のイメージまたはコンテナの偶発的な使用を防止するために、ホスト・システムから不要なイメージおよびコンテナを体系的に削除します。 Podmanの自動更新機能を使用してイメージの新バージョンの有無のチェック、および影響を受けるコンテナの自動的な再デプロイのプロセスを自動化することを検討してください。

コンテナ内のカーネル機能の理解

Oracle Linuxでは、rootユーザーが、機能と呼ばれる個別の単位に分割されます。デフォルトでは、次のカーネル機能がコンテナに付与されます。

CHOWN
DAC_OVERRIDE
FSETID
FOWNER
NET_RAW
SETGID
SETUID
SETFCAP
SETPCAP
NET_BIND_SERVICE
SYS_CHROOT
KILL

デフォルトでは、次の重要なカーネル機能がコンテナから削除されます。

SYS_TIME
MKNOD
NET_ADMIN
SYS_MODULE
SYS_NICE
SYS_ADMIN
AUDIT_WRITE

コンテナを起動するときに--privilegedオプションを使用しないでください。これは、削除された機能、限定されたデバイス、読取り専用マウント・ポイント、ボリュームなど、ホストからコンテナを分離するセキュリティ機能を無効にするためです。

コンテナ内のカーネル・ファイル・ハンドルおよびプロセス・リソースを制限するオプションの理解

コンテナを作成および実行するときは、--ulimitオプションを使用してカーネル・リソースを制限するか、Podmanサービスの起動時に--default-ulimitを使用してコンテナのデフォルトを設定します。

コンテナからのネットワーク・アクセスを制限するオプションの理解

コンテナのネットワークを実行する場合は、ホストにポートを公開するときに、コンテナによるリスニング対象のネットワーク・インタフェースに攻撃対象領域が少なくなるように、ポートをバインドするインタフェースのIPアドレスを指定します。 Podmanでは、-pまたは--publishオプションの使用時にIPアドレスを指定しないと、デフォルトですべてのインタフェース(0.0.0.0)に公開されます。

コンテナ内でSSHを実行しないでください。

コンテナ内で特権ポート(1024未満)をマップしないでください。

コンテナの起動時または実行時に、コンテナに--net=hostモード・オプションを使用しないでください。このオプションは、コンテナにローカル・システム・サービスへの完全なアクセス権限を付与するため、安全ではありません。

コンテナ内のシステム・コールを制限するオプションの理解

Podmanコンテナでは、デフォルトで、/usr/share/containers/seccomp.jsonファイル内で指定されているシステム・コールに基づいて、コンテナで使用可能になるシステム・コールが制限されます。このリストはほとんどのコンテナと互換性があるため、システム・コールを追加する必要はありません。

ホスト・ネームスペースをコンテナと共有しない

コンテナの起動時または実行時に、PIDやIPCネームスペースなどのホスト・ネームスペースを共有しないでください。

ホストデバイスをコンテナに公開しない

コンテナの起動時または実行時に、ホスト・デバイスをコンテナに公開しないでください。

コンテナ化されたアプリケーション

コンテナ化されたアプリケーションでのカーネル・コールの最小化: カーネルはコンテナ間で共有されるため、カーネル・コールはホスト・システム上で実行されている他のコンテナに対するリスクを増大させます。コンテナ化されたアプリケーション内では、可能なかぎり、カーネル・コールが使用されないようにしてください。
非rootユーザーとしてコンテナ・アプリケーションを実行します: コンテナ化されたアプリケーションがroot以外のユーザーとして実行されていることを確認します。 UIDはホスト間で共有されるため、コンテナ内のrootユーザーはホスト上のrootユーザーです。
コンテナ化されたアプリケーションでのsetuidおよびsetgidの使用の削除または最小化: ほとんどのアプリケーションでは、setuidバイナリやsetgidバイナリは必要ありません。できれば、そのようなバイナリは無効にするか削除してください。そうすることで、権限エスカレーション攻撃に使用される可能性がなくなります。 setuidまたは setgidアクセス権フラグを持つバイナリを検出した場合は、それらをすべて削除するか、アクセス権フラグを削除して、バイナリ上のこれらのアクセス権に関連するリスクを削除してください。
コンテナ化されたアプリケーションを永続的に設計: 可能なかぎり、アプリケーションはステートレスでロール可能、可能であれば即時移行できるマイクロサービス・コンテナ・アプリケーションになるように設計します。自身の設計でないアプリケーションを使用する場合は、コンテナ内で実行するソフトウェアを選択する際に、このアプローチを考慮してください。この品質を保つと、システムの侵害や不慮の事態が発生している間やその後にサービスを管理する場合に役立ちます。