Zero Touch Productionについて調べた

Zero Touch Production（ZTP）とは

Zero Touch Productionとは，Building Secure Reliable Systemsの中で書かれている本番環境を安全に変更するための考え方．本番環境のアクセス権限をもつ人が直接変更を加えるのではなく，自動化あるいはツールを介した間接的な操作により予測可能で制御された本番環境の変更を実現する．

課題の背景

本番環境を直接人が操作する環境では，入力ミスやコマンドのコピぺミス，操作するターミナルの誤りなどによって意図せず環境の破壊を行ってしまうことがある．また，本番環境へのアクセス権限をもつアカウントの乗っ取りによって悪意ある攻撃者によって任意のコマンドを実行されて環境を破壊されることも考えられる．
Googleによるとおよそ13%の本番障害が上記にあげた人による直接的な操作によるものであった．

ZTPのモデル

上記で挙げた課題に対して，ZTPでは本番環境の変更を以下の3つのいずれかに制限することを提唱している．

• 自動化された操作
• ソフトウェアによる操作の自動検証
• 監査されたブレークグラスメカニズム

ZTPを実現するモデルとして描かれているのが下図．
操作者あるいは自動化された操作は必ずプロキシを介して本番環境を操作する．プロキシは操作者あるいは自動化システムの権限をチェックする，また，同時に操作ログも起録する．加えて，承認が必要な操作については承認者に許可を要求し，承認されたら実行できるメカニズムになっている．

このモデルのデメリットももちろんある．例えば以下のような点が挙げられる．

• プロキシの運用，保守コストの増大
• プロキシが単一障害点となってしまうので，高いSLAを求められる
• プロキシ自身に強い権限をもたせてしまうと乗っ取りリスクが増大する（そのため，必ず操作者や自動化システムの権限で操作するような仕組みとしなければならない）

GoogleではGoogle Tool Proxyと呼ぶCLIツールを作成してZTPを実現している．
このCLIツールにはあらかじめ設定としてロールや承認者を記述しておくことで，危険な操作の場合にプロキシが自動的に承認者へ承認要求を送り許可されたら実行するというツールのよう．

ZTPのはじめの一歩を考えてみる

例えばAWSで本番環境を構築したとして，AWS CLIのラッパーとしてGoogle Tool Proxyのような高度なツールを作るのはかなりコストが高いように思える．ZTPのはじめの一歩としては次のようなものだろうか．

• 定常的な変更はCI/CDパイプラインを介して自動化する
  言うまでもないが定常的な変更はCodePipeline，CodeBuild，CodeDeployをつかって自動化するのがよいだろう．
• 削除などの破壊的な操作権限はデフォルトでは割り当てず，必要時に申請するようにする
  削除のような本番環境を破壊する可能性のある危険な操作権限はデフォルトで割り当てない，必要な場合はAWS Simple Workflowを使って一時的な特権アクセス要求を行う．例えばこのブログに記載のような方法．また，このときポリシーの有効期限を設定することで適切に特権アクセスを管理できそう．
• CloudTrailで操作ログを取得

こう考えると，基本的には最小権限の原則に従ったIAMポリシー設計と特権アクセス管理の問題をきちんと設計できれば，ある程度はZTPの背景にある課題感は解決できそうにも思える．そのあたりのベストプラクティスはAWSのドキュメントにいいものがあるかもしれない．