Windows Server 2016 コンテナー

アプリケーションおよび計算リソースの規模と範囲を縮小することで、アプリケーション開発インフラのセキュリティを向上させることができます。その方法の1つが、ワークロードをコンテナー化することです。Windows Server と Microsoft Hyper-V のコンテナーを使うことで、ワークロードを互いに、さらに OS から分離できます。万一攻撃者がコンテナーを侵害したとしても、攻撃者がホスト OS にアクセスするのは難しくなります。コンテナーは、開発・テスト・本番チーム向けに標準化された環境も提供します。

コンテナ

コンテナは、アプリに対して分離された移植可能な実行環境を提供します。アプリの観点から見ると、コンテナは、それ自身のファイルシステム、デバイス、構成を備えた、完全に分離された Windows OS のように見えます。したがって多くの点で、コンテナは VM（仮想マシン）と同様です。つまり、OS を実行し、ファイルシステムをサポートし、他の物理マシンや VM と同じようにネットワーク越しにアクセスできるためです。

コンテナは、ホスト OS のカーネルを共有しつつ、ユーザー空間の分離を提供する仮想環境です。したがってコンテナは、アプリが OS の残りのユーザーモードの構成要素に影響を与えず、また他のユーザーモードの構成要素からも影響を受けずに実行できる理想的な環境を提供します。コンテナを使うことで、開発者は隔離された環境内で、限られた OS リソースのみを使用しながら、アプリを素早く作成・テストできます。つまり、コンテナは、VM 上の OS が使用するかもしれないすべてのプロセスやサービスを必要としません。

Windows Server 2016 は 2 種類のコンテナをサポートしています：

• Windows Server コンテナー。 これらのコンテナーは、プロセスと名前空間の分離技術によってアプリケーションを分離します。Windows Server コンテナーは、コンテナ ホストおよびホスト上で実行される他のすべてのコンテナーと OS カーネルを共有します。
• Hyper-V コンテナー。 これらのコンテナーは、各コンテナーを高度に最適化された VM 上で実行することで、Windows Server コンテナーが提供する分離をさらに拡張します。

コンテナーの利用には複数の利点があります。OS サイズが小さくなることで、維持すべきオペレーティング システム コンポーネントが少なくなり、その結果、潜在的なセキュリティ リスクも減ります。さらに、OS サイズの削減はスケーラビリティの向上にも役立ちます。

Docker

コンテナーでアプリケーションのワークロードを実行するには、Docker を使用する必要があります。Docker は、オープンソースのツールとクラウドベースのサービスの集合体であり、アプリコードをパッケージ化（コンテナー化）して、ソフトウェア開発用の標準化された単位にまとめるための共通モデルを提供します。この標準化された単位、つまり Docker コンテナーは、実行に必要なものがすべて含まれる完全なファイルシステムで包まれたソフトウェアです。これには、コード、ランタイム、システムツール、システムライブラリ、そしてサーバーにインストールできるその他のすべてが含まれます。Docker は別途ダウンロードする必要があります。Docker は Windows Server 2016 のインストールメディアに含まれていません。

Nano Server

Microsoft Nano Server は、Windows Server 2016 向けの比較的新しいインストール オプションです。これは、仮想化されたコンテナー インスタンスでの使用に合わせて設計された軽量なオペレーティング システムです。UI はありません。Nano Server は PowerShell を使ってリモートで管理する必要がありますが、この PowerShell は標準のものとは異なります。Windows Server バージョン 1803 以降、Nano Server はコンテナー ベースの OS イメージとしてのみ利用でき、Docker などのコンテナー ホスト上でコンテナーとして実行する必要があります。これらの新しい Nano コンテナーは、Docker を使ってトラブルシューティングし、IoT Core で実行できます。

Nano Server インスタンスは Active Directory ドメイン コントローラーとして機能することはできません。特に、次の機能をサポートしていません。

• グループ ポリシー
• ネットワークインターフェイスカードのティーミング
• 仮想ホストバスアダプター
• プロキシサーバーによるインターネットへのアクセス
• System Center Configuration Manager
• System Center Data Protection Manager

Nano Server は次のロールをサポートしています:

• ファイル サービス
• Hyper-V
• IIS
• DNS サーバー

よくある質問（FAQ）

Windows Server 2016 のコンテナーを権限昇格（privilege escalation）から守るにはどうすればよいですか？

Windows のコンテナーを保護することは、identity から始まります。なぜなら data security identity から始まるデータセキュリティとは、コンテナーのレベルで「誰が何にアクセスできるか」を制御することを意味するためです。Windows Server 2016 のコンテナーは既定でプロセス隔離（process isolation）で実行されるため、ある程度の保護は提供されますが、権限昇格（privilege escalation） 攻撃を防ぐには、階層化されたセキュリティ制御が必要です。

まず、可能な限り非管理者のユーザーアカウントでコンテナーを実行し、最小権限の原則を徹底します。Dockerfile の USER ディレクティブを使って低権限のアカウントを指定し、どうしても必要な場合を除き、コンテナーを Local System や Administrator として実行しないでください。さらに、コンテナーのリソース制限を設定して、権限昇格（privilege escalation）につながり得るリソース枯渇（resource exhaustion）攻撃を防ぎます。

ドメイン認証が必要なコンテナーには、グループ管理サービス アカウント（group-managed service accounts、gMSAs）を導入します。これにより自動パスワード管理が提供され、資格情報の露出を抑えられます。Windows Defender Application Control のポリシーを設定して、コンテナー内で実行できるアプリケーションを制限し、悪意のあるコードの実行に対する追加の障壁を作成してください。

強化された分離のために、機密データを扱う際は Windows Server コンテナーではなく Hyper-V コンテナーを使用してください。Hyper-V コンテナーはハードウェアレベルの分離を提供し、攻撃者による横方向の移動（lateral movement）を大幅に困難にします。コンテナーへのアクセスおよび認証イベントを継続的に監視してください。見えないものは管理できず、リスクのある挙動が侵害につながる前に見抜くには、コンテナーの活動をリアルタイムで把握できる必要があります。

Windows Event Forwarding を有効にしてコンテナーのセキュリティログを一元化し、Security Event Log の監視を設定して、コンテナー内での認証失敗、特権昇格の試行、疑わしいプロセス作成を確認してください。デプロイ前にコンテナーイメージを定期的にセキュリティスキャンすることで、既知の脆弱性が本番環境に到達するのを防ぐのに役立ちます。

Windows コンテナーにはアイデンティティ管理上どのような影響がありますか？

Windows コンテナーはホストのセキュリティコンテキストを継承するため、データのセキュリティ態勢に直接影響する独自のアイデンティティ管理上の課題が生じます。従来の VM とは異なり、コンテナーはホスト OS のカーネルを共有するため、コンテナーの認証情報が侵害されると、ホストシステム全体に影響が及ぶ可能性があります。

コンテナーのプロセスは特定の Windows ユーザーアカウントの下で実行され、その識別子（アイデンティティ）が、各コンテナーがアクセスできるデータおよびシステムリソースを決定します。コンテナーを大規模に展開すると、実質的にアイデンティティの攻撃対象領域が増えます。つまり、各コンテナーが認証情報の窃取や横方向の移動（lateral movement）攻撃の潜在的な侵入口になり得るのです。

実際の影響として、コンテナーのID戦略は、より広範な identity governance プログラムと統合する必要があります。ドメイン認証が必要なコンテナー処理には group-managed service accounts (gMSAs) を使用してください。gMSA は自動パスワード管理を提供し、資格情報をコンテナーイメージに保存する必要をなくします。コンテナーの ID を、環境内の他のあらゆる privileged account と同様に扱う identity ベースのアクセス制御を実装し、適切なローテーション、監視、最小権限の強制を行ってください。

コンテナー固有の ID に関する課題として、コンテナーの再起動をまたいだ資格情報の保持（credential persistence）、資格情報を安全に注入する方法、そして動的なコンテナー環境におけるサービスアカウントのライフサイクル管理などを検討してください。identity management ソリューションでは、どのコンテナーがどの ID を使用しているのか、またそれらがどのリソースにアクセスしているのかが可視化できる必要があります。

Windows コンテナーのアクセスと権限をどのように監査しますか？

効果的なコンテナー監査には、ホストレベルとコンテナーレベルの両方の活動に対する可視性が必要です。攻撃者は侵入するだけでなくログインも行うためです。Windows コンテナーは標準の Windows イベント ロギング システムによってセキュリティイベントを生成しますが、コンテナー固有の活動を記録するには追加のログ設定が必要です。

コンテナーの作成、変更、削除のイベントを追跡するために、コンテナー実行時ログ（container runtime logging）を有効化します。Windows イベント ロギングを構成し、コンテナー内での認証イベント、特権昇格の試行、そしてリソースへのアクセスパターンを取得してください。想定していないアクセスとして、たとえばコンテナーが期待しているデータボリューム以外のファイルにアクセスしたり、予期しないネットワーク接続を行ったりしていないかに重点を置いて監視します。

ポイントは、コンテナの活動をより広範なセキュリティ監視戦略と関連付けることです。コンテナのアクセスイベントは、従来のユーザーアカウント監視と並行して、Identity and access governance のプログラムに投入する必要があります。敏感なデータリポジトリへのアクセスを試みる、またはコンテナが意図されている範囲を超えて権限を昇格させようとするなど、高リスクなコンテナ挙動に対して自動アラートを設定してください。この先回りのアプローチにより、リスクのある挙動が侵害につながる前に見つけられます。

コンテナがアクセスしてはいけない機密ディレクトリに対してファイルシステム監査を実装し、コンテナ内でのプロセス作成イベントを監視して、許可されていない実行ファイルの起動を検出します。PowerShell ログを使用して、コンテナ内の管理アクティビティを記録してください。特に、自動化スクリプトや管理ツールを実行するコンテナでは重要です。

Windows コンテナのセキュリティ監視では、どのようなベストプラクティスに従うべきですか？

コンテナのセキュリティ監視は、従来のサーバー監視とは異なるアプローチが必要です。コンテナは一時的（ephemeral）であり、動的な攻撃面を作り出すためです。まず、コンテナのライフサイクルイベント――作成、開始、停止、削除――のベースライン監視から始め、通常の運用パターンを確立してください。

ホストとコンテナの両方のレベルでネットワークトラフィックを監視し、横方向の移動（lateral movement）やデータの持ち出し（data exfiltration attempts）を示唆する可能性のある異常な通信パターンを検出します。CPU、メモリ、ディスク使用量といったリソース消費指標を追跡して、コンテナ内で潜在的なサービス拒否攻撃や暗号資産マイニング活動を特定してください。

コンテナーのファイル システム変更をリアルタイムで監視します。特に、ディスクに書き込むべきではないコンテナーに重点を置いてください。Windows Performance Toolkit と、コンテナー固有の監視ツールを使用して、コンテナー内でのプロセス実行を追跡し、不正なプロセスや予期しない特権昇格の試みを監視します。目的は可視性と制御の強化です。コンテナー環境全体で何が起きているのかを把握することで、効果的なセキュリティ対応を行えるようになります。

未承認のレジストリからのイメージ取得、過剰な権限で実行されているコンテナー、またはホスト システムのリソースにアクセスしようとするコンテナーなど、コンテナー固有のセキュリティ イベントを監視するように設定します。ネットワーク接続先が通常と異常な宛先になっている場合や、通常のベースラインを超えてリソースを消費している場合など、期待される動作パターンから逸脱したコンテナーに対してアラートを設定してください。

Windows コンテナーの認証問題はどのようにトラブルシューティングしますか？

コンテナーの認証問題は、設定ミスのあるサービス アカウント、またはホスト環境とコンテナー環境の間における認証情報（クレデンシャル）の管理不備によって起きることがよくあります。まず、コンテナーが正しい Windows の識別（identity）を使用していることを確認してください。Process Monitor や Windows Event Viewer などのツールで、コンテナー プロセスがどのセキュリティ コンテキストで実行されているかを確認することから始めます。

よくある認証の失敗は、資格情報の委任（credential delegation）に問題があるために、コンテナーがドメイン リソースにアクセスできない場合に発生します。コンテナーが Active Directory やその他のドメイン サービスに対して認証する必要がある場合は、従来のサービス アカウントではなく、グループ管理サービス アカウント（gMSAs）を使用していることを確認してください。gMSAs は自動的なパスワード管理を提供し、コンテナーのシナリオを想定して設計されています。

コンテナホストとドメインコントローラーの両方で、認証関連のエラーがないか Windows イベントログを確認してください。ログオンの失敗、Kerberos 認証の問題、または NTLM 認証の問題に関連するイベント ID を探します。Network Monitor や Wireshark などのツールを使用して認証トラフィックをキャプチャし、認証チェーンがどこで途切れているかを特定してください。コンテナの認証問題は、多くの場合、全体的なセキュリティ体制に影響し得る、より広範な Identity Management の問題を示していることを覚えておいてください。

コンテナホストがドメインに正しく参加していること、また必要な Windows 機能（たとえば PowerShell 用の Active Directory モジュール）がインストールされていることを確認してください。コンテナ内で DNS 解決が機能し、ドメインコントローラーに到達できるかを確認します。資格情報の委任（credential delegation）を使用している場合は、コンテナホストのアカウントに Active Directory 上で必要な委任権限があることを確認してください。