どうもセキュリティエンジニアリングの西川です。禁酒しています。誘惑多い GW を超えたので勝ったも同然です。とはいえ、お酒は飲まずとも酒の場は好きなのでお気軽に誘っていただけると嬉しいです。
さて、今日はカミナシで去年より実施している Production Readiness Check についてお伝えできればと思っています。
Production Readiness Check とは何か
プロダクションレディマイクロサービスという書籍が出ています。書籍の紹介に下記のようにあります。
UberのSRE（サイト信頼性エンジニア、サイトリライアビリティエンジニア）として、マイクロサービスの本番対応向上を担当していた著者が、その取り組みから得られた知見をまとめたものです。モノリス（一枚岩）を複数のマイクロサービスに分割した後に、安定性、信頼性、スケーラビリティ、耐障害性、パフォーマンス、監視、ドキュメント、大惨事対応を備えたシステムにするために必要な原則と標準に焦点を当て、本番対応力のあるマイクロサービスを構築する手法を紹介します。本書で採用している原則と標準は、マイクロサービスだけなく多くのサービスやアプリケーションの改善にも威力を発揮します。
というようにセキュリティというよりは SRE 文脈で語られることが多く、セキュリティは Production Readiness Check の中の一部の項目として存在しています。しかしながらカミナシでは逆にセキュリティを中心にチェックリストを作成しています。
また、書籍の付録で紹介されているチェックリストは抽象的な内容が多く、達成しているかどうかの基準を設けたり、それを本当に達成しているかどうかを確認するとなるとかなりの工数が必要であることがわかります。
カミナシではプロダクションレディネスチェックを1-2週間以内に完了させて事業計画にあわせ素早くリリースすることを目指しているのでスコープを狭めています。また、まだチーム数も少ないですし、セキュリティ以外のインフラの安定性や信頼性に関して極力同じアーキテクチャやマネージドサービスを採用することで担保しています。
なぜ Production Readiness Checklist を作るのか
では、カミナシでなぜ Production Readiness Checklist を作ろうと思ったかというところですが、カミナシでは複数のプロダクトを提供しており、それらのプロダクトの最低限のセキュリティを担保する必要があります。Production Readiness Checklist で対応しなくとも SAST(Static Application Security Testing) や DAST(Dynamic Application Security Testing) 、脆弱性診断などによって担保するということも考えられるかもしれませんが、過検知によって開発スピードが下がってしまうことは避けたかったのと、アプリケーション以外のセキュリティに関する項目やバックアップの保存期間など社内標準のチェックの用途には不十分であるため作成しました。
そういった状況から私たちセキュリティエンジニアリングはカミナシに必要な最低限のセキュリティ施策を洗い出し、それをリリース前にチェックすることにしています。実際のチェックではセキュリティエンジニアリングが各開発チームのメンバーと一緒に行い ”できているか/できていないか/やらないか、できていないならいつできるか/やらないならその理由は何か” を確認していて、おおよそ1回の確認が2時間程度で終わるような内容となっています。
具体的には、「Cookie に HTTPOnly 属性が設定されていること」や「バリデーションはサーバーサイド側で行われていること」などなど、基本的には「はい」か「いいえ」で答えられる項目を用意して短い時間で確認できるようにしており、本記事を書いている時点では55個の項目をチェックしています。
また、狙ったことではありませんでしたが、複数のプロダクトで、ある程度同じ仕組みや信頼性を担保できることにより、顧客から送られてくるセキュリティチェックリストへの回答が容易になりました。これがバラバラな技術でバラバラにセキュリティ対策が取られているとそれぞれの内容を書かないといけないので辛いところがありますが、それが軽減されています。
実際に運用してみてどうか
手前味噌ですが良い感触を得ています。それはプロダクト自体がセキュアになることもそうですし、開発メンバーが持っていなかったセキュリティの観点をインプットすることができるからです。私たちの Production Readiness Check では具体的なやることに対して、 ”なぜやるのか” も文章として明記しています。そうすることでその対策の必要性を開発者にインプットしています。また色々と方針を策定していますが、その方針通りに実装できているかどうかを確認する手段にもなりますし、方針自体が知られていなければ方針を改めて知ってもらう機会になるのでとても良い機会になっています。
実際、開発者と一緒にチェックをしていると、「この観点抜け落ちていました」ということがあったりするのですが、セキュリティの観点が抜け落ちていることを責めるというよりも彼らにセキュリティの知識をインプットできることが喜びだったりします。
ただ、現時点ではサービスのリリース時だけ確認しているのですが、定期的にみていく必要性を感じています。理由としては、ある時設定が意図的にしろ、そうでないにしろ変わっていたみたいなことが考えられるためです。ですので、ある程度は Checklist の項目を自動的にチェックしたいと思っています。また、リリース時に必ずしも対応している必要はないが、ある基準を満たした場合には対応を MUST にするというような項目もあります。サービスの特性にもよりますが、そういう条件を設けなければ対策が too much になってしまいかねないのでその辺のバランスを取るようにしています。
Production Readiness Check を作成するにあたって参考になるもの
私たちは去年作成していたので参考にできるものがあったわけではないのですが、最近立て続けに Production Readiness Check に参考になる資料ができてたので紹介します。1つ目が SANS が出している Security Checklist for Web Application です。 www.sans.org Web Application に特化した Security Checklist で使えるものが多いです。
もう1つが Flatt Security 社が下記の資料を出してくださっていて、その内容が要点を押さえたすごく勉強になるものなのでこちらもお勧めです。 speakerdeck.com
おわりに
いかがでしたでしょうか、皆さんの組織でも Production Readiness Check 始めてみませんか？もちろんセキュリティに限らず SRE 文脈で始めるのも良いと思います。また、すでに始めていらっしゃる方は工夫している点などいろいろ情報交換させてもらえるとありがたいです。
