最近歩くだけで疲れやすくなった「ぎだじゅん」です。
ライフイズテックという会社でサービス開発部 インフラ/SREグループに所属しています。

体を動かすことも億劫になり運動する機会も減りましたが、そんな日常の中で、唯一ハードな運動と言えるのが、アーティストのライブに行くことです。

先日参加したライブでは、ディスコ(?)やクラブなどで流れる音楽のように曲間のMCやブレイクなどはなく、20曲以上ぶっ通しのノンストップミックスで会場のボルテージが上がりっぱなしでした。

♪ドンッ、ツゥー、ドンッ、ツゥーって感じで繰り返されるリズムで2時間ほど洒落たステップを踏み続けた結果、足腰も♪鈍痛ぅ〜、鈍痛ぅ〜となり、ライブが終わったころには、心地よい疲労感を超えた節々の痛みで足を引きずりながら帰ったのは良い思い出です。
そんな、体の脆弱性がどんどん増えていると感じる、今日この頃です。

本題です。

セキュリティ対策の変化

プロダクトのセキュリティ対策として、ファイアウォールやWAFなどを導入して、入り口をしっかり守る対策などをされている会社は昔から多いと思います。

しかし、本来は侵入対策だけでなく、侵入されることを想定しての対策や開発からリリースまでの各工程における対策なども踏まえた「多層防御」や、リリース直前やテスト工程よりも前の段階でセキュリティ対策を講じる「シフトレフト」などの必要性が高くなってきています。

これは、昔に比べて、セキュリティの重要性が社会全体で高くなってきていることや、環境基盤がクラウドにシフトしてきたこと、開発サイクルも変わってきたことなどが影響していると自分は考えています。

DevSecOpsを目指す

弊社のプロダクトのサービスでは、AWSによる環境上にアプリケーションをデプロイしてサービスが稼働しています。

クラウドやコンテナ、サーバレス技術により、短時間での環境構築やシステムのライフサイクル管理ができるようになりましたが、これによりセキュリティ対策の方法も大きく変わりました。

クラウドサービスのいろいろなコンポーネントを組み合わせてシステム環境を構築するケースが多いと思います。
そのようなケースで、通信やデータの暗号化、ログ記録、鍵管理、作業権限管理など、それぞれのコンポーネントでこれらのセキュリティの設定不備がないかの確認は重要です。

環境構築からリリースまでの流れもIaCやCI/CDなどにより、インフラ構築やアプリケーションのリリースなどをコードで管理する事がスタンダード化してきており、自動化のパイプラインやコードに対してもセキュリティの問題がないかをチェックして対策する必要があります。

また、どこでどのような原因で問題や脅威が発生しているかを検出するには、それぞれの機能やサービスで出力されるログの相関分析から状況を可視化して異常時に検出をしたりする仕組みが必要です。
（過去に実施した例を以下でも紹介してます）

いろいろな仕組みと連携してWebアプリケーションの稼働環境が構築され、アプリケーションのリリースも自動化されていくことから、Webアプリケーションの入り口の対策のみならず、開発からリリースまでの各プロセスの内部での対策も含めた「多層防御」は重要となり、それぞれのレイヤーで多層的に対策をおこなうことがベストプラクティスとなっています。

そもそもDevSecOpsってなに？

AWSでは以下のように説明しています。

DevSecOpsを実現するためには、DevOpsによるプロセスを通して多層防御のセキュリティ対策を行う必要があると考えています。

クラウドの「責任共有モデル」

クラウドを利用するんだからアプリケーションだけセキュリティ対策していればいいのと考えている方は、さすがに少なくなってきたとは思います。
ほとんどのクラウド事業者では以下のような責任共有モデルというものを公開しています。

クラウド環境を利用する場合でも、クラウド上のデータやアプリケーションは当然のこと、クラウド上でのアクセス管理やネットワーク制御、OS（IaaSの場合）、ミドルウェア、通信やデータの暗号化などはクラウド利用者側が責任を持つ必要があります。

クラウド事業者では、利用者側でこれらの範囲のセキュリティをカバーできるようなソリューションを提供してくれていたり、サードパーティーのツールやサービスで対策できるものなどがあるので、これらのソリューションを使って、セキュリティ対策を実施しています。

セキュリティ対策の種類

前述の責任共有モデルで利用者が対応すべき内容を網羅するようなソリューションの中、自社プロダクト環境でのセキュリティ対策にて該当するものを中心にピックアップしました。

• CSPM（Cloud Security Posture Management）

  • クラウド環境でのユーザ/ロール権限管理やネットワーク、ストレージ、アプリケーション実行環境などの各種設定におけるセキュリティの不備や構成の問題などを継続的に確認して、インフラ環境のセキュリティリスクを低減する

• CWPP（Cloud Workload Protection Platform）

  • IaC（Infrastructure as Code）やCI/CDに潜むセキュリティリスク、サーバやコンテナなどのアプリケーション実行環境やソフトウェアに潜む脆弱性などがないかをチェックする

• SIEM（Security Information and Event Management）

  • ネットワークやサーバ、セキュリティプロダクトなどのログを一元的に集約し相互関係を分析してインシデントを検知する

続いて、アプリケーションに対してのセキュリティ対策としては以下のものがあります。

• SCA（Software Composition Analysis）

  • アプリケーション内で使用するOSS（オープンソースソフトウェア）のミドルウェアやライブラリを識別して脆弱性のあるソフトウェアがないかを特定する

• SAST（Static Application Security Testing）

  • アプリケーションのソースコードを解析して、不適切なコーディングパターンがないかなどの脆弱性を検出する

• DAST（Dynamic Application Security Testing）

  • 実際にアプリケーションが稼働している環境に対して疑似的に攻撃をおこない、アプリケーション上に潜む脆弱性を発見する

マネージドサービス活用でDevSecOpsを実現

ライフイズテックではDevSecOpsのセキュリティ対策に対して、以下のようなサービスを活用して実現しています。
各サービスの詳しい内容はサービス名のリンクをクリックして参照ください。

• インフラ環境における対策

  • AWS Security Hub によるクラウド環境の設定チェック（CSPM）

  • TerraformでのIaCにおける tflintによるコードの記述チェックと  tfsecによるコードのセキュリティチェック（CWPP）

  • Amazon Inspector によるインスタンスのOSやパッケージの脆弱性チェック（CWPP）

  • Amazon GuardDuty によるAWSクラウド環境上での脅威検出（CWPP？）

  • Datadog による各種ログからの状況の可視化と脅威検知（SIEM）

• アプリケーション開発における対策

  • Snyk Open Source によるOSSパッケージやライブラリの脆弱性チェック（SCA）

  • Snyk Code によるコードの脆弱性チェック（SAST）

• ビルドやリリース工程における対策

  • Snyk Container におけるコンテナイメージの脆弱性チェック（SCA）

  • Securify によるWebアプリケーションの脆弱性チェック（DAST）

他にも、多層防御での入り口対策としてAWS WAFや、出口対策としてAmazon Macieなど、AWSのサービスや関連するソリューションサービスなどを有効的に使用しています。

これらの対策は、以下のチームで運用しています。

1. インフラ環境における対策

   • インフラ/SREチームのメンバーで導入から運用までおこなっている

2. アプリケーション開発における対策とビルドやリリース工程における対策

   • 以下はインフラ/SREチームでおこなっている

     • セキュリティ対策ソリューションの導入

     • 検出内容の初手の確認

     • 対応後の再チェック

   • 以下はインフラ/SREチームと開発チームで協議

     • 脆弱性対応のトリアージ（対応の必要性や優先度の判断）

   • 以下は開発チームでおこなっている

     • 脆弱性に対しての改修

他にもいろいろ導入検討中

これら以外にも、昨年末にGuardDutyによるECSのランタイム脅威検知がリリースされたり、DatadogのApplication Security Management (ASM) や SnykのAppRisk などのようなアプリケーション内でどのようなコンテキストで攻撃を受けているかを可視化できるサービスなどがあり、いずれもとてもよい機能で検証を進めています。

シフトレフトによるセキュリティ対策

Webアプリケーションによるプロダクトでは、速いスピードで移り変わっていく消費者のニーズに対応していくため、アジャイル開発のように機能開発や改善を「設計」→「コーディング」→「テスト」→「リリース」の開発サイクルを小さく短いスパンで繰り返して進めていく必要があります。

このような開発サイクルの場合、リリース直前の最終工程で脆弱性が見つかると、修正対応による遅延がサービスの機会損失などに繋がる可能性があります。

そこで、Webアプリケーションに潜む脆弱性に対して、シフトレフトの考え方で、以下のようなサービスを使ってセキュリティへの取り組みを開発サイクルの早い段階でおこなうことで、リリース直前でのセキュリティ診断等での検出による修正などの差し戻しのリスクを軽減させています。

Snyk

Snykはソフトウェアの脆弱性を発見し修正するためのセキュリティプラットフォームです。
SDLC（Software Development Life Cycle）の中で、アプリケーション開発者が作成するコードや、オープンソースライブラリ、コンテナイメージの安全性を継続的に確保できるようアプリケーションセキュリティを支援してくれます。

Snykには以下の4種類の機能があり（現在は5種類あるようでした）、ライフイズテックではSnyk IaC以外を使用しています。
（現在はSnyk IaCの代わりに Terraformでの tflint を使用）

• Snyk Code

  • コーディング中のコードやGitHubのリポジトリ上にあるコードから、ソースコードの脆弱性となりそうな文法の記述やコードにハードコードされているシークレットキー情報などの機密情報を検知する

• Snyk Open Source

  • GitHubのリポジトリにあるソースコードから、公開された脆弱性を含むバージョンを使用していないかなど、オープンソースの依存関係に存在するセキュリティ脆弱性やライセンス問題を検知する

• Snyk Container

  • Docker HubのリポジトリにあるコンテナイメージやDockerfileのセキュリティスキャンを実施してイメージに含まれるオープンソースの依存関係に存在するセキュリティ脆弱性を検知する

• Snyk IaC （未導入）

  • TerraformやCloudFormationのコードが脆弱性を含む構築になっているかや、シークレットキーなどの秘密情報が記載されている可能性がないかを検知する

これらの各機能において、Snykが持つ脆弱性に関するデータベースから脆弱性を検出してくれます。
以下のSnykの資料にもありますが、これらをDevOpsでの各プロセスに組み込むことで、DevSecOpsを実現することができます。

弊社でも、以下のように開発作業フェーズや開発環境での検証前のイメージビルド時などのプロセスで実施して、脆弱性がないかを確認しています。

• Snyk Code のスキャン実施プロセス

  • Code作成またはGitHubリポジトリへのSubmit時に対策を実施

    1. コードエディターのIDEプラグイン/CLI や GitHubリポジトリの作業ブランチへのコミット時にコードスキャンが自動で実施

    2. コード上での脆弱性のある実装や秘密情報を含む箇所の検出結果や、該当の脆弱内容の説明、修正案をWebコンソールの「Code Analysis」で確認。
       またはコードエディター上のIDEプラグインやCLIの実行結果で確認。

    3. 開発チームで修正して動作検証をおこなう

• Snyk Open Source のスキャン実施プロセス

  • GitHubリポジトリへのSubmit時に対策を実施

    1. GitHubリポジトリの作業ブランチへのコミット時に、パッケージやライブラリの情報ファイル（nodeだとpackage-lock.jsonやpackage.jsonなど）からオープンソースソフトウェアのセキュリティスキャンを自動で実施

    2. 既知の脆弱性を含むバージョンを使用しているパッケージやライブラリをリストアップ

       • 該当の脆弱内容の説明（CVS情報やSnykによる脆弱性解説）や、修正案（対応しているバージョン情報など）をWebコンソールで確認

    3. 検出されたパッケージやライブラリに対して脆弱性対応されたバージョンが提供されている場合は、アップデートを実施して動作検証をおこなう

• Snyk Container のスキャン実施プロセス

  • GitHubリポジトリへのSubmit時やDocker Hubへのイメージビルド後に対策を実施

    1. GitHubリポジトリの作業ブランチへのコミット時のDockerfileの構成内容からや、Docker Hubに対してCI/CDでのイメージビルド後のコンテナイメージからセキュリティスキャンを自動で実施

    2. 既知の脆弱性を含むバージョンを使用しているベースイメージやパッケージ、ライブラリをリストアップ

       • 該当の脆弱内容の説明（CVS情報やSnykによる脆弱性解説）や、修正案（対応しているバージョン情報など）をWebコンソールで確認

    3. 検出されたパッケージやライブラリに対して脆弱性対応されたバージョンが提供されている場合は、アップデートを実施して動作検証をおこなう

Snykでは検出されたそれぞれの脆弱性ごとに脆弱性の内容や対策案の提示をしてくれたり、Snyk Open Source と Snyk Container （Dockerfile）においてGitHubリポジトリと連携をしている場合は、脆弱性のあったパッケージやミドルウェアについて、脆弱性対応がされているバージョンへ修正した内容でSnyk側からプルリクエストをして修正を進めることも可能です。

Snykでは検出されたそれぞれの脆弱性ごとに脆弱性の内容や対策案の提示をしてくれたり、脆弱性のあったパッケージやミドルウェアについて、脆弱性対応がされているバージョンへ修正した内容でSnyk側からプルリクエストをして修正を進めることも可能です。

• プルリクエストによる修正は Snyk Open Source と Snyk Container （Dockerfile）においてGitHubリポジトリと連携が必要

• サービスの利用に関係なくSnykが持つ脆弱性データベースによる脆弱性情報も公開されています（パッケージ名やCVE番号で検索できます）

DevOpsに関する様々なツールとのインテグレーションもサポートしており、GitOpsやイメージビルド、コンテナへのデプロイなどクラウドネイティブな開発プロセスをおこなっているようであれば、使用するツールや工程にあわせてSnykによるセキュリティ対策を導入しやすいと思います。

最後に

今回、多層防御とシフトレフトによるDevSecOpsを各種サービスを活用して実現している旨を紹介しました。

今回、シフトレフトに関してSnykを使った例を紹介しましたが、開発プロセスのサイクルの中でWebアプリケーション診断サービス「Securify」も導入しております。
こちらについては、次回に掘り下げて紹介したいと思います。

AWSや関連するサービスプロバイダーなどでは、DevSecOpsを実現するためのいろいろなソリューションを提供してくれています。
セキュリティで気を使う箇所が増えて大変な業務ではありますが、いろんなサービスを駆使して効率よく運用し、空いた時間で自分の体の脆弱性もケアしていきましょう！！

気の知れた少数のメンバーでいろんなサービスを活用して効率化を目指している今の会社はとてもいい会社なので、興味のある方はこちらも是非見てみてください。

あと、気軽にご参加いただけるカジュアルなイベントもたまに実施していますので、興味のあるイベントがあれば、ぜひ参加してみてください。