次にコンテナ利用における責任です。
コンテナを採用するにあたって参考にすべき基準はいくつかありますが、ここでは代表的なNISTという基準を参照します。
それによると、コンテナ利用においては、１から５のようなリスク、つまりセキュリティのポイントが出てきます。これらはすべて自社で構築したインフラで対応しようとするとセキュリティ工数の増大につながるため、可能であれば、各種セキュリティ基準を満たしたマネージドサービスの利用をお勧めします。
弊社の場合ですと、①イメージリスクや、④コンテナリスク、稼働するコンテナ以外の部分をPCI DSSという基準を満たしたマネージドサービスで構成し、責任範囲を狭めています。

--統制の変更

まず、統制に関しては、
① APIアクセスを前提とした、証跡取得または保管
② 社内申請システムへのID・権限追加と権限付与の仕組みの導入
③ セキュリティ要件や共通のインフラの制限を考慮した本番環境アクセス制御
の3点に対応していく必要があります。

これらは、会社ごとの仕組みの差異が大きく、弊社も依然として対応している状況ではありますが、反省も含めて簡単に対応ポイントを共有します。

まず、全ての前提として、ID管理の整理をきちんと行いましょう。AWSであれば、アカウント、ユーザー、グループ、ロール、ポリシーがそれに該当します。そのうえでクラウドを利用するプロジェクトや、必要な環境の種類、クラウドを利用する人の役割の分類等を考慮しID、権限の作成基準を定めます。
そのうえで、事前に定義された手順やコードを用いて、IDや権限を作成しましょう。

① については、オンプレミスの各種サーバーログインを前提とした証跡取得から、APIアクセスを前提としたクラウド版の証跡取得への変更をします。ただ、それぞれのクラウドサービスの監査系のマネージャーサービスを用いていれば、証跡の保護や保存、またその後の分析などはそれほど難しいことではないと思います。
② については、現状利用している申請システムにおいて、前述のような整理された方法で、IDや権限を追加したうえで、申請・承認のフローを回すことができるか、承認者を含めて事前に運用を確認すべきでしょう。また、権限付与を自動化する場合は、クラウドへのインターネット経由のAPIアクセスが前提のため、新たな仕組みを考える必要があるでしょう
③ については、特に慎重になる必要があります。というのも、一般的に本番環境へのアクセスについてはアクセス元端末や端末が存在する部屋への入室制限、アクセス元ネットワークなど、多くの物理的かつ統制上変更が難しい制限がある共通インフラの利用を前提とした場合が多いからです。弊社では、アカウントを環境、サービスごとに分け、個別のIDを用意し、本番用のIDのみ接続元をわけることで本番環境アクセスの制御を実現しています。

--セキュリティ対策方法の変更

次にセキュリティ対策の変更です。
一般的には脆弱性スキャンやWebアプリケーション保護などレイヤーごとに様々な対策があります。弊社の場合、それらはセキュリティ基準や社内外の要件を満たしたマネージドサービスを利用しました。プラスαを工夫したところとして一例を紹介します。

--改ざん検知

まず、改ざん検知対策としてリードオンリーコンテイナーとすることで 、そもそも改ざんできないような仕組みを導入しています。AWSの場合だと、コンテナ定義に以下のような設定を追加することでリードオンリーコンテナの構築は可能です。
ただ、コンテナ上で稼働するアプリケーションに影響を与えますので、十分な検証を行ってから導入してください。

--ウィルス対策：コンテナイメージスキャン

コンテナイメージに対しては、脆弱性スキャンだけでなくウイルススキャンも実行しています。方法としては、OSSのスキャンツールをインストールしたサーバーをスキャンのために構築し、各種テスト後にスキャンを実行しています。
その後セキュリティ担当のチェックを受けたイメージのみ本番環境にデプロイできるような状態にしています。

スキャンのたびに構築するというのは、スキャンツールの特性を生かすために重要な過程です。そもそもスキャンツールは最新のセキュリティー情報を複数の外部サイトから取得し内部のデータベースに格納します。そのデータをもとにイメージから構築されるコンテナ内のOSパッケージや依存ライブラリなどのソフトウェアを一つずつ調査していくことで常に最新の情報でスキャンすることができます。

--アウトバウンド通信制限：FQDNベースフィルタリング