最近よく聞く、DevSecOps というワード。DevOps にセキュリティが追加されたものということなのですが、DevOps からして、何となくなイメージしかなかったので詳しく調べてみました。
こんにちは、 narai です。
このあいだ「NGINX App Protect が DevSecOps を実現させるためのツールとして有効である」という話を聞きましたが、なぜなのか漠然としていたので、 DevSecOps について詳しく調べてみました。
DevOps について
DevSecOps は DevOps にセキュリティを追加したものということで、まずは DevOps について調べてみました。
DevOps は厳密に定義化されているわけではなく、抽象化されたものです。
一言でいうと、
「お客様に安全でより良いサービスを迅速に提供できることを目的として、開発チームと運用チームがお互いに協力連携できる組織体制のための企業文化や環境」となります。
これは、開発チームと運用チームではミッションが異なるため、開発者は「お客様のために新機能を早く追加したい」と考え、運用者は「お客様のために安定的なサービスを提供したい」と考えるケースが多く、対立が生じやすくなっていました。
ただ、どちらも “お客様のため” という最終的な目的は同じであるため、この問題を解決して共通の目的達成に向けて連携するための活動について、定義したものが DevOps になります。
では、協力連携できる組織体制を作るためにはどうしたらよいのでしょうか。それには重要となる 3 つの要素があります。
なお、DevOps は概念であり、実現のための方法は各企業の環境や状況によって様々です。
そのため、ここでは一般的に言われている要素についてまとめました。
文化とは企業組織であり、人になります。
開発担当者と運用担当者がお互いに協力し合える関係を組織的に築くのが大切となり、そのために以下の考えを持つことが重要となります。
- Respect : 相手のことを尊敬し合い、能力や功績を称えあう
- Trust : 互いに信頼し合い、役割に応じて仕事を任せる
- Healthy attitude about failure : 失敗は起こるものなので相手を責めない
- Avoiding Blame : 失敗が起こらないように建設的な議論をすすめる
DevOps の手段
開発者と運用者の双方のミッションを達成するための方法として、CI/CD の仕組みを取り入れます。
CI とは「継続的インテグレーション」と呼ばれ、0 から 100 の変更を加える際、一度に 0 → 100 へするのではなく、0 → 10 , 10 → 20 と小さい変更を繰り返し行う方法となります。
こうすることで、問題が発生した際の原因の特定や対処が早く楽になります。
CD とは、「継続的デリバリー」と呼ばれ、変更されたコードを自動的にビルドして、テスト環境にデプロイする仕組みです。
こうすることで、すぐに動作確認が行えるようになります。
CI/CD を取り入れ、小さな変更を都度都度確認することで、「新機能の追加と安定的なサービス」の両方を満たす仕組みとなります。
DevOps の実行
小さい変更を行うたびに、チェックして環境を作って動作確認をしていては、「より良いサービスを迅速に提供」することができません。
そのために、ツールを導入して自動化するのですが、ツールは 1 種類ではなく、各フェーズにおいて様々なツールを組み合わせることで実行していきます。
フェーズ毎のツールとして代表的なものとしては
- コード管理の `github` や `gitlab`
- CI/CD のための `jenkins` や `circleci`
- サービス実行環境の `kubernetes` や `Amazon EKS`
- インフラ設定管理の `ansible` や `terraform`
- コミュニケーションのための `slack`
等があります。
これらのツールを使って、開発担当者と運用担当者が協力して変更 → 確認 → リリース → 変更のサイクルをまわしていくことが DevOps となります。
さて、上述の通り DevOps によって、お客様により良いサービスを迅速に提供できるようになりました。
しかしながら、問題点もあります。それが、セキュリティです。
小さな変更で頻繁に発生するリリースの度に、脆弱性や重大な不具合のセキュリティチェックを行う必要があるため、工数が増えリリースが遅くなるといった懸念が生まれました。
そこで、DevOps にセキュリティも統合して、フェーズ全体を通してセキュリティを意識しようという概念が DevSecOps です。
では、DevOps にセキュリティも統合するためにはどうしたらよいのでしょうか。それには重要となる 3 つの要素があります。
セキュリティのシフトレフト
リリースのフェーズになってから、セキュリティテストや施策を行うのではなく、開発やテストといった早い段階からセキュリティ施策やテストを行うこと仕組みです。
セキュリティチェックのタイミングがフェーズの左側に移動することから、シフトレフトと呼ばれます。
DevOps のスピードを保つこと
単純にフェーズの早い段階からセキュリティを意識して、テストやチェックを繰り返しただけでは、負荷が増えリリースまでのスピードが低下してしまいます。
そのため、サービスのセキュリティポリシーを明確にして、チェックや判断を自動化することで負荷を軽減して、素早く対応できる仕組みを作ることが大切です。
DevSecOps の実行
DevOps 同様、DevSecOps を実現するために各フェーズにおいて様々なツールを組み合わせることで実行していきます。
各フェーズ毎のツールとしては
- 開発中のソースコードに内在する重大な不具合や脆弱性を検出する静的解析ツール(SAST)
- オープンソースやサードパーティのモジュールに内在する脆弱性をチェックするソフトウェア構成分析ツール(SCA)
- 従来から活用されている脆弱性診断ツール(DAST)
- 実行中のアプリケーションの振る舞いを監視するツール(IAST)
- アプリケーションを攻撃から守るツール (WAF , Firewall)
DevSecOps とは
DevOps と DevSecOps ともに「お客様に安全でより良いサービスを迅速に提供できる」ことを目的に、今までのようなフェーズ毎の役割分担ではなく、一つのサービスに対して全員が責任を持つための仕組みが DevSecOps (DevOps) なんだと理解しました。
そのため、ツールを導入しただけでは目的は果たせず、組織文化や考え方といった意識の改善、体制やプロセスといった仕組みの改善が非常に重要だということがわかりました。
まとめ
NGINX App Protect はアプリケーションを攻撃から守る WAF です。
ただ、単なる WAF ではありません。web サーバーとして広く使われている NGINX が WAF の機能を持ったのです。
DevSecOps においては、開発者も運用者もセキュリティを意識する必要があります。そんな中、ほとんど触れたことのない WAF 製品まで考慮するのは、開発者、運用者に負荷がかかりスピードを保つことが難しくなるかもしれません。
そこで、web サーバーとして慣れ親しんだ NGINX を WAF として利用したら「お客様に安全でより良いサービスを迅速に提供できる」ようになるのではないでしょうか。
これが、「NGINX App Protect が DevSecOps を実現させるためのツールとして有効である」ということなんだとわかりました。
NGINX App Protect が DevSecOps で有効である説明は、Jo Nishikawa さんが動画で詳しく説明してくれているので、ぜひこちらも見てみてください。
最後まで読んでいただきありがとうございました。
また、次の更新をお楽しみに。
