こんにちは、Nissho Electronics USAの小松です。
皆さまはGoogle Mapが提供しているオフラインマップという機能をご存知でしょうか。私はつい最近知りましたが、昔からある機能で電波の良いエリアであらかじめ必要なエリアマップをダウンロードしておくことで、圏外エリアでもGoogle Mapの音声ナビを提供してくれる機能です。国土が広いアメリカでは圏外エリアも多く非常に便利な機能なので、もしご出張時やご旅行時にナビが無いと不安という方は是非活用してみてください。レンタカーにオプションでナビをつけるのも高額ですので。
さて、今回はDocker（ドッカー）等に代表されるコンテナをトピックとして、ここ最近、より議論が進むコンテナセキュリティを取り上げたいと思います。特にアプリケーションやソフトウェア開発に携わる皆さまにおいては、自社開発環境を利用する際、あるいは外部クラウド等の開発環境を活用する際に少なからず考慮しておく点として参考にして頂ければと思います。
ますます普及が進むコンテナ
Docker（ドッカー）に代表されるコンテナサービスの普及が進んでいることはみなさまも少なからず肌で感じていらっしゃるのではないかと思います。かつてはLinuxのみだったコンテナが、いまやWindows、データセンターからクラウドに至るまであらゆるシーンで利用されています。Amazon AWS、Microsoft Azure、Google GCP上でのコンテナサービス普及の勢いを見てもテクノロジーならびにビジネストレンドの1つであることは間違いありません。米451 Researchによる市場予測でも2020年には約3000億円もの市場になるといわれています。
リスクが潜むソフトウェア/アプリ開発における一連のプロセス
コンテナのキーワードとともに良く取り上げられるのは、DevOps、マイクロサービスでしょう。
従来のウォーターフォール型ソフトウェア開発も勿論必要ですが、クラウドサービスが当たり前になり、そのうえで動作するアプリケーションやソフトウェア開発がより重要になった現在ではアジャイル、つまり俊敏性を施された開発プロセスは欠かせません。当然ながらセキュリティも重要な要素の1つです。今回はそのセキュリティにポイントを絞りますが、セキュリティを押さえていくうえで、一般的なアプリケーション、ソフトウェア開発プロセスをおさらいしておきます。
- Devシステムが、コンテナイメージをつくって、テスト、評価フェーズへ
- 無事テストを通過したコンテナイメージはレジストリに保存
- レジストリからオーケストレータがある場合は、展開され、複数コンテナイメージを統合したり、ホストへ展開
- ホスト上で実行、動作
簡単に見えるコンテナプロセスですが、作成、テスト、デプロイと分業になっているため、各々のポイントで考慮すべきセキュリティ対策がありそうです。では各ポイントでどのようなリスクが潜んでいるのが見ていきたいと思います。
5つのコアコンポーネントが常に脆弱性の脅威にさらされている
5つのポイントが全てとは言い切れませんが、一般的な共通項としてリスクが潜むポイントとして押さえておくべきものとして以下が挙げられます。
1. イメージに潜むリスク
- 内部ファイルのアップデート不足による脆弱性侵入
- コンフィグ誤り
- ファイルパッケージの集合体ゆえに、疑わしいマルウェアが潜む場合あり
- 大事なID/Pass情報を含むアプリが直接イメージ内に集約されていること
- 外部アクセスや連携が容易になることで、トラブルシュート時等に信頼のないソフトウェアを実行してしまう
2. レジストリに潜むリスク
- レジストリへの通信が中間者攻撃などで妨害、データ盗難にあう
- レジストリ内データが期限切れや古くなっていると、脆弱性侵入の恐れがある
- 不十分な認証作業により、コンテナ、ホストへ悪影響を及ぼす
3. オーケストレータに潜むリスク
- 管理者権限が横断的かつ複数チームに割り当てられてることによるリスクや不十分な権限マネージメント
- オーケストレータによる仮想的なオーバーレイネットワークは時にセキュリティ対策が見えなくなっている
- 脆弱なコンフィグレーションによる、不正なホストのクラスタ侵入や認証鍵が全てのノードで共有されている
4. コンテナに潜むリスク
- ランタイムソフトウェア内の脆弱性
- 各コンテナが他コンテナやホストOSと自由に通信できるチャネル上に存在すること
- 管理者が柔軟に構成変更できるということは、ある意味攻撃者にとっても同様である
- コンテナ上のアプリケーション自身の脆弱性に影響を受けるなど
5. ホストOSに潜むリスク
- そもそもが大きなAttack Surface（攻撃対象領域）となりうる
- 結局ハイパーバイザーほどのセキュアな隔離は施されない
- ファイル改ざんなど
では、これらリスクに備えるために何をすべきかNISTが推奨する対策をピックアップして共有させて頂きたいと思います。
NISTが推奨する各コンポーネントへのセキュリティ対策抜粋（一部）
1. イメージリスクに備えるには？
- コンテナに特化した脆弱性マネジメントツールを利用する
- コンプライアンスに準拠したツールやプロセスを採用する
- 全てのイメージ上でマルウェア監視を実行する
- 信頼されたイメージのみを自社環境で実行する
2. レジストリリスクに備えるには？
- レジストリへのアクセスは必ず暗号化されたチャネルを活用する
- 古いイメージを削除、あるいか新しいイメージにタグをつけ区別する
- 重要機密コンテンツへのアクセスには必ず認証を施す
3. オーケストレータリスクに備えるには？
- なんでもかんでも管理者権限を与えない
- 重要レベルに応じてチャネルを分割する
4. コンテナリスクに備えるには？
- 脆弱性を早く検知して対処するために、ランタイムを継続的に監視しておく
- コンテナランタイムに自動的にコンプライアンスチェックを施す
- コンテナはRead-onlyモードで
- Development、Test、Production環境は分割し、コンテナデプロイとマネジメントのためにルールベースのアクセス制御を施す
5. ホストOSリスクに備えるには？
- コンテナ特化のHost OSを利用し、アップデートは欠かさないこと
- ホストOSに対する認証、ログイン監視を強化するなど
コンテナセキュリティベンダーも一長一短、自社にあった対策を
既に数多くのコンテナセキュリティベンダーが世の中には存在していますが、やはり各社それぞれ得意としている領域やコンセプトが異なります。
セキュリティ対策を施す対象レイヤを低レイヤにするのか高レイヤにするのか、コンテナ内部なのかコンテナ間セキュリティを強化するのか、コンプライアンス対策まで意識するのか。ビジュアライズやセキュリティプロセスの自動化、オーケストレータ等の連携がどこまでできるようになっているかも重要なポイントでしょう。いくつかお試し頂き、前述したポイントを押さえながら自社にあった対策を頂くことを推奨いたしますが、我々もUS現地の事例等より最適解を発信していきたいと思います。
最後までお読みいただきありがとうございました。Nissho Electronics USAではシリコンバレーから旬な最新情報を提供しています。 こんなことを調べてほしい！などございましたら問い合わせページよりぜひご連絡ください。
