セキュリティを担保するのは難しい
だが「コンテナは便利だが、セキュリティ面で気をつければならないことがある」と野原氏は続ける。
「コンテナはカーネルを共有するが、そのカーネルを共有しているところがきちんと独立しているか。コンテナ専用OS、例えばRPMのパッケージがインストールできないなどのセキュリティをどう確保していくか。さらにコンテナはライフサイクルが特殊なので、その辺をどう継続的に見ていくかなどの課題があります」（野原氏）
Dockerを使うときは、まずDockerファイルを記述する。このDockerファイルの1行1行はDockerのイメージレイヤとして、sha256:ハッシュ値のディレクトリに収納される。そして、これらのディレクトリを集めたものが1つのコンテナのイメージになる。
「こういった環境で、ホストからセキュリティを提供するようなケースでは、ホストで見つかった脆弱性を、sha256:ハッシュ値のディレクトリからイメージにひも付きけることは難しい」（野原氏）
また、Dockerは重複排除の機能があるため、同じsha256のハッシュ値を持つディレクトリであれば、1つを残して排除されることになる。つまり、このときにつけた脆弱性がイメージとしてその1つだけにひも付いているのかどうか、人の手で探すのは困難であると言うのだ。それだけではない。Dockerはスケールアウト・スケールインの動きも独特であることも影響する。
「例えば、クラウドネイティブでアプリケーションの特定のアドレスや特定の機器にひも付かず動くという前提でつくってほしいと言われるとします。このような考え方はコンテナオーケストレーターにも取り入れられているため、Kubernetesの環境で、4ノードのクラスタの中に3つのコンテナをデプロイしたとします。明示的に指定しなければどこにデプロイされるか分かりません。このような環境でスケールアウトする場合は、今動いているのにプラスしていけばよいが、スケールインする場合は、どこのクラスタにどのコンテナが残るか分かりません。こういった動きをするコンテナに対して、特定のノードや特定のアドレスの形のセキュリティのアプローチは通用しないのです」（野原氏）
コンテナ環境は設定変更やバージョンアップの方法が通常のアプローチと異なる。従来の仮想マシンであれば、問題が起きるとログインをして修正をして、その仮想マシンを運用し直せばよかった。
だが、コンテナは元のイメージをリビルドして、入れ替えるというアプローチのライフサイクルになる。したがって、セキュリティのアプローチも変わってくる。コンテナは画一的なイメージの利用を前提としているため、そこで想定されない動きがないことを監視していくアプローチに変えなければならない。
コンテナの実行環境の構成にも注意が必要になる。インフラはもちろん、Runtimeや関連ツールのバージョン、docker.sockに対する権限、ホストディレクトリのマウント状況、環境変数でコンテナに渡すクリアテキストのパスワード、イメージの脆弱性、ランタイム挙動の監視などのコンテナの構成、さらにはKubernetesやetcd、CoreDNSなどのコンポーネントのバージョンや設定など、コンテナオーケストレーターも脆弱性を持ちうるので見ていかなければならない。
例えば、環境変数の部分。MySQLのイメージを動かすときに、「docker run -e MYSQL_ROOT_PASSWORD」といった環境変数を渡す方法を採用していたとする。この場合「docker inspect」やKubernetesであれば「kubectl describe」というコマンドで、ホストから簡単にパスワードが見えてしまう。
Dockerfileの記述においても注意が必要だ。パスワードを入れるのは論外だが、JSON Web Tokenのファイルをコピーして、何か処理をし、その後削除するというプログラムでも、コンテナからは見えなくなっているがレイヤには残っているので、ファイルシステムから見えてしまうという問題がある。そのほかにも便利なイメージを使いたいという開発者の気持ちを悪用し、Docker Hubにマイニングスクリプトが仕掛けるという例もあるそうだ。
DevSecOpsを実現するためのツールとは
つまり、「コンテナ環境のセキュリティは従来とは異なるアプローチが必要になる」と野原氏。ではどのような方法があるのか。その最適解は「NIST SP.800-190というコンテナに特化したガイドラインに準拠したコンテナセキュリティツールを使うことをお勧めする」と野原氏は言う。
どのようなツールを使って環境をセキュアにしていけばよいのか。野原氏はGitHubとCircleCI、JFrog Artifactory、JFrog Xray、Twistlock（現在の名称はPrisma Cloud Compute）を紹介する。CircleCIはGitHubとシームレスに連携するCI/CDツール。
JFrog Artifactoryは10年以上の実績がある成果物管理システムで、27種のパッケージ管理やリポジトリのプロキシ機能、アクセス制御などを提供する。JFrog XrayはArtifactoryのオプションとして使え、Artifactory上のデータにセキュティ（脆弱性診断とライセンスチェック）とそれに連動するアクセス制御を提供する。TwistlockはKubernetesのノードやコンテナホストにエージェント導入することで、コンテナの脆弱性、マルウェア検知・コンプライアンスを静的にスキャン。また、実行環境においても機械学習ベースのランタイム監視を行うほか、CIツールへの組み込みも可能。
Dockerのイメージやサーバレス、IaC（TerraformやAWS CloudFormation、Kubernetesのマニュフェストも含まれる）のスキャンができる。もちろん、NISR SP800-190に準拠している。これらのツールを組み合わせていくのだが、この際に注意すべきポイントが2つある。「シフトレフトと自動化」である。
つまり、なるべくDev側でチェックするようにすることと、人手を介さないように自動化することだ。シフトレフトされた側だけではなく、運用環境でのセキュリティの自動化を検討していかなければならない。こうすることで、DevOpsを継続しつつ、計画以外のすべてのところでセキュリティを担保することができるそうだ。
実際に今回紹介した構成とほぼ同じ環境で2種類のデモを実施。最後に野原氏は、「正しいツールを組み合わせて使うことで、運用環境、開発環境に効率的にセキュリティを自動適用できるようになります」とセッションを締めた。
