2023年10月23日 (月) から 12月8日 (金) にかけてRECRUIT Internship for Engineers, Data Specialists 2023に参加させていただいた櫛引淳之介です。インターン期間中は『スタディサプリENGLISH』のSREチームに配属され、社内ツール用インフラの構築や、インフラ開発環境のセキュリティに関するタスクに取り組みました。今回は、メインのタスクとして取り組んだインフラのセキュリティ検査ツールの導入について紹介します。

はじめに

パブリッククラウドの設定不備は、セキュリティインシデントの原因となります。手作業による確認では見逃しが発生する可能性があるため、設定不備の検知自動化を進める動きがあります。
『スタディサプリENGLISH』ではインフラとしてAWSを使用しており、その設定にはソースコードによってインフラ構成を管理できるIaCツールのTerraformが使用されています。CIに組み込まれたConftestで設定不備のスキャンを行っています。Conftestは、入力データ（今回の場合、Terraformの出力するインフラ設定情報）がRego言語¹⁾宣言型のクエリ言語で、構造化データが満たすべきポリシーを記述するために使用される。で書かれたポリシーを満たしているかチェックすることができるツールです。ここで使われているポリシーは全てSREチームのエンジニアが自分たちで記述したものであり、検査対象となる設定が限定されている点が課題となっていました。
そこで、今回のインターンシップでは、専用の検査ツールにより検査対象を広げることで、より不備の入り込みにくい開発環境を実現することを目指しました。具体的には、ツールの選定、ポリシーセットの調整、CIへの組み込みを行いました。

ツールの選定

今回は、導入するツールの選定から取り組みました。AWSやTerraformのセキュリティ検査を行うツールは多数存在しますが、今回は以下のような条件で候補を絞り込み、最終的にAqua Securityの提供するOSSであるTrivyを使用することにしました。

• TerraformとKubernetesの設定にセキュリティ上の不備がないか検査できる
• ポリシーセットに一定の信頼を置ける
• ポリシーの除外・追加がしやすい
• 開発・利用が活発に行われている

以下では、これらの条件の詳細について説明します。

TerraformとKubernetesの設定にセキュリティ上の不備がないか検査できる

インフラ関連のセキュリティ検査ツールの対象は広く、コンテナイメージ、AWSアカウント、Linuxファイルシステム、各種IaCなど様々なシステムに対応するものが存在します。
今回のツール導入では、インフラ更新時の設定ミスの混入を防ぐことを目的としているため、SREグループで採用しているTerraformのソースコードをCIで検査できるものを候補としました。
加えて、Kubernetesの設定ファイルも同時に検査したいという意見が挙がったため、両方に対応していることを条件として選定を行いました。

ポリシーセットに一定の信頼を置ける

今回調査対象とした各ツールは、それぞれが独自に定義したポリシーセットを検査に用います。検査の要であるポリシーセットに一定の信頼を置けるツールを採用したいと考え、調査を行いました。
具体的には、AWSのセキュリティ設定におけるベストプラクティス集として広く用いられているCIS AWS Foundations Benchmarkに記載されている内容を検査できるようになっているか調査しました。Trivyは単体でCIS v1.2.0とCIS v1.4.0での検査とレポート出力に対応しており²⁾CIS AWS Foundations BenchmarkのReccomendationには自動検査の可否を示すAssessment Statusという項目があります。自動検査のできないものについてはTrivyでも検査できないものと考えられます。、ポリシーセットの妥当性を一定程度信頼できるものと判断しました。

ポリシーの除外・追加がしやすい

どんなに優れたポリシーセットを使っていたとしても、機械的に検査を行う以上は過剰検知を避けられません。『スタディサプリENGLISH』のインフラ構成に合わせて必要のないポリシーによる検査をスキップできることは、実運用上必須と考えました。詳細は後述しますが、具体的には、特定のポリシーによるエラーの抑制、特定リソースに対するエラーの抑制、Dev環境とProd環境でのエラー抑制ルールの変更ができることを条件として調査を行いました。その結果、Trivyのほかにも、CheckovやTerrascanといったツールが候補に上がりました。
また、将来的にConftestの使用をやめてツールを一本化するニーズが生じる可能性があると考え、自前でポリシーを追加できるかどうかも考慮に入れました。TrivyにはCustom Policyという機能があり、Conftestと同じくRego言語を使ってポリシーを記述することができます。

開発・利用が活発に行われている

長期の運用を想定すると、機能やポリシーのメンテナンスと更新が安定して継続されることが望ましいと考えられます。GitHubのStar数を調べたところ、2023年10月時点でTrivyは19.3kであり、他のツールと比較しても人気があることがわかりました。コミュニティの活発さから、Trivyであれば今後も継続的にメンテナンスされることを期待できると考えました。

Trivyの導入

今回は、Dev環境でTerraformのソースコードが更新された際に設定ミスがないか検査できるようTrivyの導入作業を行いました。

ポリシーセットの調整とコードの修正

TrivyでDev環境のコードを検査してみたところ、予想していた通り383件ものポリシー違反が出てしまい、本当に確認すべきポリシー違反があっても埋もれてしまう状況でした。そこで、不要な検査はスキップするようポリシーセットの調整を行い、必要のある箇所についてはコードの修正も行いました。
先述の通り、Trivyでは、二つの方法で検査をスキップできます。一つは、.trivyignore ファイルにポリシーのIDを記述する方法です。.trivyignore に記述されたポリシーによる検査はスキップされます。運用上全く必要のないポリシーはこの方法で無視します。

# Security Group: Add Descripion To Security Group Rule
AVD-AWS-0124
# Security Group: No Public Egress Sgr
AVD-AWS-0104

もう一つは、リソースにコメントを記述する方法です。Terraformに書いたリソース定義の上にポリシーIDを記述することで、当該リソースでのみ指定したポリシーによる検査をスキップできます。原則として検査してほしいものの、例外もあるような場合にはこの方法を使います。

# trivy:ignore:AVD-AWS-0107 No Public Ingress Sgr
resource "aws_security_group" "example" {
  name        = "example"
  description = "example"
  vpc_id      = aws_vpc.example.id
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    "Name" = "example"
  }
}

Dev環境のコードを検査して表示された各ポリシー違反について、以下いずれの対応を取るか判断し、変更を実施しました。

• ポリシーを .trivyignore に記載して検査をスキップする
• リソースにコメントをつけて検査をスキップする
• Trivyの出すエラーに従って修正を行う

不要とはいえない検査の中にも、設定変更のコストとポリシー違反のまま稼働させることのリスクを天秤にかけた結果、既存リソースについては修正を行わずコメントによってスキップしたものもあります。
また、今回はDev環境で使用することを想定して .trivyignore ファイルを作成しましたが、Dev環境では検査をスキップしたくても、Prod環境では検査してほしいポリシーもあります。今回の調整で作成した .trivyignore ファイル中のポリシーのうちの4種類については、Prod環境で検査に使用することとしました。
最終的に、21種類のポリシー基づく検査を .trivyignore でスキップさせ、55件の検査をリソースにコメントを付与することでスキップさせました。また、2種類のポリシーに違反するリソースを修正したほか、9種類のポリシーについては違反するリソースを修正可能かどうか検証することとしました。

CIへの組み込み

ポリシーセットの調整後、TrivyをCIに組み込みました。Terraformのコードを変更すると、Pull Requestの更新時にTrivyによる検査が実施されます。ここでポリシー違反が発見された場合、PR上にレビューコメントが投稿されます。検査の実行とコメントの投稿には、 suzuki-shunsuke/trivy-config-actionを使用しました。

その他の活動

インターン期間中には、メインの業務以外にもチームメンバーの方々が取り組んでいる活動に参加させていただきました。

IPv6勉強会

インターン参加期間中には開発部で「プロフェッショナルIPv6 第2版」の輪読会が開催されており、私も3度参加させていただきました。大学院ではIPv6のセキュリティに関する研究に取り組んでいるので、「第14章 IPv6とセキュリティ」の回で研究内容を発表させていただきました。質疑応答では非常に多くのコメントや質問をいただき、新しい技術を貪欲に学び議論する文化があることを肌で感じました。なによりも、研究の内容に興味を持っていただけて嬉しかったです。

交流の機会

そのほかにも、出社時のランチ会、社員の方や他のインターン生との「よもやま」³⁾リクルート用語で、アジェンダ不要で気軽に行われる1on1ミーティングを指す。
参考：リクルートの「よもやま」ミーティングとは？ フラットなコミュニケーションが個性を活かす | 株式会社リクルート、部活動の見学など、チーム内外の方との交流の機会もありました。個々人の意志を尊重する風土がありながら、オンライン・オフライン問わずコミュニケーションがとても活発で、心理的安全性の高さを感じました。また、インターン全体の企画として、懇親会やエンジニア社員の方とのトークイベントもあり、お祭りのような充実した7週間でした。

おわりに

インフラの設定ミスによるインシデント対策を未然に防ぐため、セキュリティ検査ツールのTrivyを導入しました。Terraformのコードを更新するPRをトリガーにTrivyによる検査が実行され、設定ミスが発見されるとコメントがつきます。今後の課題として、Kubernetesの設定ファイルについても検査対象とすることが挙げられます。

インターン期間中は、受け入れチームの皆さん、人事事務局の皆さんをはじめ、大勢の方のお世話になりました。関係者の皆さん、ありがとうございました。