DevOpsにおけるセキュリティのシフトレフト外観

この記事は[SRE Advent Calendar 2021](https://qiita.com/advent-calendar/2021/site-reliability-engineering)の20日目の記事になります。

## はじめに

こんにちは。SREをやったりやってなかったりする[@toro_ponz](https://twitter.com/toro_ponz)です。
最近はSREとしていわゆるDevOpsの実践などを中心に、ソフトウェア品質の計測や向上などに努めております。
巷ではこの頃、DevOpsに付随してDevSecOpsといわれるワードが見聞きされるようになってきました。**log4shell脆弱性(CVE-2021-44228)**などが話題になったりと、セキュリティの重要性は言うまでもありません。今回は**DevOpsにおけるセキュリティのシフトレフト**という概念について触れられればと思います。

## DevOpsとは

まずはじめにざっくりDevOpsの概念について軽く触れておきます。
DevOpsとは端的に言えば『**開発チーム(Dev)と運用チーム(Ops)が連携してソフトウェア開発プロセスを進めソフトウェア開発品質の向上に寄与する**』こと、またその要素をまとめた**インターフェース**です。
このDevOpsというインターフェースを実践するために**SRE**というチームが存在し、後述するような各要素を改善していく具体的施策を施行していくことになります。Googleはこの構図を『**class SRE implements DevOps**』という有名なワードで表現しています。

### DevOpsを構成する要素

では、実際に何を改善することでソフトウェア開発における品質が高いと言えるのか、ひいてはDevOpsを実践できているのかという指標ですが、[LeanとDevOpsの科学](https://book.impress.co.jp/books/1118101029)ではソフトウェア開発の競争力を示す指標としてDevOpsを**24ケイパビリティ**、**5カテゴリ**に分類しています。

- **継続的デリバリ**
    - バージョン管理、デプロイの自動化、継続的インテグレーション、トランクベースの開発、テストの自動化、テストデータの管理、**情報セキュリティのシフトレフト**、継続的デリバリ
- **アーキテクチャ**
    - 疎結合のアーキテクチャ、チームへの権限の付与
- **製品とプロセス**
    - 顧客フィードバック、業務プロセスの可視化、作業の細分化、チームによる実験
- **リーン思考に基づく管理と監視**
    - 変更承認プロセス、監視、プロアクティブな通知、進行中の作業の制限、作業の可視化
- **組織文化**
    - 創造的な組織文化、学びの支援、チーム間の協働、職務満足度、改善を促進するリーダーシップ

そしてそれぞれを評価し向上していくことがソフトウェアの競争力につながり、最終的にはプロダクト、そして企業としての事業成果につながるという研究結果が得られているという訳です。

これらの24のケイパビリティのうちの一つとして、**継続的デリバリ**に分類される**情報セキュリティのシフトレフト**があり、同カテゴリの**トランクベース開発**や**テストの自動化**、**デプロイメントプロセスの自動化**などと合わせて改善していく必要があります。

## 情報セキュリティのシフトレフトとは

改めて本題です。
DevOpsにおける**情報セキュリティのシフトレフト**とは、ひとことで言うと『**開発プロセスの初期段階からセキュリティ品質を管理する**』ことです。[GoogleのDevOpsのページ](https://cloud.google.com/architecture/devops/devops-tech-shifting-left-on-security)には、下記のような記述があります。

> DevOps Research and Assessment（DORA）（PDF）の調査では、プロセスの最後にセキュリティの問題をテストするのではなく、セキュリティを日常業務の一部に組み込むことで、より良い結果を達成できることが示されています。これは、セキュリティ テストとコントロールを開発、QA、運用の日常業務に統合することを意味します。

昨今一般的なセキュリティ品質の管理手法としては、リリース前にQA環境などで行われる**脆弱性診断**や、**ペネトレーションテスト**などが広く普及していると思います。しかし、いわゆるソフトウェア開発の一般的なプロセスにおける最終段階およびそれに近い段階でセキュリティの品質を担保するよりも、より**手前の段階**で**継続的**かつ**小さいサイズ**でのセキュリティ問題の検出、テストを行うことが重要だということです。
この開発プロセスにおける初期段階を**左**そして最終段階を**右**と表し、**シフトレフト**していくことが、本要素であり、ソフトウェア開発の競争力を向上させることにつながります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262177/ee8817d2-e117-a14f-c01a-5bbafb855df9.png)

以降は、[DevOps 技術: セキュリティのシフトレフト | Google Cloud](https://cloud.google.com/architecture/devops/devops-tech-shifting-left-on-security?hl=ja)を参考に具体的な実践例について自分なりの解釈をいくつか解説します。

### 1. 開発プロセスへの人の組み込み

アジャイル開発など小さいサイクルで開発プロセスが素早く進められるようなものでは往々にして、セキュリティや負荷などの考慮が設計段階では不十分で、開発中および開発後のテストプロセスにおいて問題が顕在化することがあります。それらの手戻りを改善するために開発プロセスの初期段階である設計時にセキュリティに関心のある者によるレビューを導入します。GoogleのページではInfoSecチームと呼称されていますが、小中規模においてはSREチームやインフラチームなどが担う形になるでしょう。セキュリティに加え負荷対策などの観点でのネガティブチェックなども行え、導入の障壁は比較的低く感じられます。注意点としてセキュリティレビューによって設計プロセスに大幅な遅れが発生しないように連携して進める必要があります。また同様に、設計時だけでなく開発およびデモやデバッグに参加してもらうことでより高い品質を維持しながら開発プロセスを回すことができるようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262177/30b32988-b29e-c404-e8dc-a6b3638de4c4.png)

とはいえ、明らかに属人的なため、これらの施策を持って全てのセキュリティリスクを回避できるわけではなさそうです。また、担当できる人員が開発チームに比べ圧倒的に少ないという問題もGoogleは記載しています。

### 2. セキュリティ検証済みのツールを開発する

[DevOps 技術: セキュリティのシフトレフト | Google Cloud](https://cloud.google.com/architecture/devops/devops-tech-shifting-left-on-security?hl=ja)には、この項目は下記のような記述で解説されています。

> InfoSec チームによる検証済みのライブラリとツールをデベロッパーに提供することで、デベロッパー コードの標準化を進めることができます。標準コードを使用するとで、InfoSec チームによるコードの検証時間を短縮できます。また、デベロッパーが事前に承認されたライブラリを使用していることを自動的にテストできます。

例えば、Kubernetesに乗せるマイクロサービスのDockerfile用の**ベースイメージ**をSREチームで用意し、SREチームはそのイメージのメンテナンスを行います。同様に、開発チームはSREチームの用意したベースイメージから**アプリケーションイメージ**のDockerfileを作成することで、関心ごとを分離しOSやLinuxパッケージなどのセキュリティをSREチームで担保することができます(解釈が間違っていたらコメントいただけると幸いです)。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262177/3baf8d31-c6b7-d480-8b49-0b523e41d610.png)


### 3. 開発プロセスへの自動テストの組み込み

DevOpsにおいて継続的デプロイ、継続的インテグレーションの要素はとても重要です。セキュリティについてもこれらの自動化されたプロセスに組み込むことが、もっとも開発効率を向上させると言っても過言ではなさそうです。

#### 3-1. セキュリティ要件テスト

開発しているアプリケーションに対しユニットテストやインテグレーションテストを導入し機能要件を満たしているかを確認するのと同じように、セキュリティ要件についても自動テストを組み込む必要があります。これは、「この場合このメソッドは呼び出されていないこと」といったユニットテストレベルの要件から、「認証情報がないAPIリクエストが403になること」といったインテグレーションテストに加え、IAMなどクラウドインフラの設定が正しいかどうかのチェックなど多岐にわたります。
話は若干逸れますが、最後の項目について例えばAWSでは**AWS IAM Access Analyzer**などによって過剰な権限がないかや、**AWS Config Rules**でリソースの正しい状態を定義しそれに合致しているかどうかなどを定期的にチェックすることができます。

#### 3-2. 脆弱性診断

脆弱性診断といえど、そのすべてを人の手で行っているわけではありません。とりわけWebアプリケーションにおいては**OWASP ZAP**などの**脆弱性診断ツール**などが存在します。
例えば[zap-cli](https://github.com/Grunny/zap-cli)などを定期的に実行するように構築することで、絶えず開発が行われるソフトウェア開発でデグレによる脆弱性などのリスクを抑えることができると思います。

また、冒頭で軽く触れたlog4shellなどのCVE番号が付くようなOS、パッケージ、ライブラリなどの脆弱性についても自動検出を行うことができます。AWSのマネージドサービスである[**AWS Inspector**](https://aws.amazon.com/jp/inspector/)では、EC2やECRイメージに対して脆弱性スキャンなどが行え、CVE情報を利用してシビラリティ付けしてくれます。DevOpsに則ってマイクロサービス化やコンテナ技術の採用を推し進めていれば、イメージのpushという開発サイクルに落とし込みやすい形で脆弱性スキャンを行えるでしょう。また、**AWS Inspector**はpushフック以外にも定期的なスキャンも行えるため、開発が比較的落ち着いた**運用段階のアプリケーション**についても有用です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262177/9aaa47cf-2722-8d7c-b457-c1f40bf8078e.png)


## まとめ

- DevOpsのセキュリティシフトレフトとはセキュリティ問題の検出をソフトウェア開発プロセスにおける右(後段階)から左(前段階)にすること
- 開発においてセキュリティを担当する人員を設計プロセスから参画させ品質を向上させる
- DevOpsにおける継続的デリバリの要素を改善していくことでセキュリティ問題の検出を開発サイクルの中に落とし込みやすい
- クラウドを利用している場合は提供されているマネージドサービスを利用すると便利

## 参考文献

- [DevOps とは: 研究とソリューション | Google Cloud](https://cloud.google.com/devops)
- [LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する - インプレスブックス](https://book.impress.co.jp/books/1118101029)