Flatt Security Blog

株式会社Flatt Securityの公式ブログです。プロダクト開発やプロダクトセキュリティに関する技術的な知見・トレンドを伝える記事を発信しています。

株式会社Flatt Securityの公式ブログです。
プロダクト開発やプロダクトセキュリティに関する技術的な知見・トレンドを伝える記事を発信しています。

セキュリティ SaaS を「プログラマブル」に再設計した話 ― Shisho Cloud の正式リリースによせて

技術 サービス紹介 Shisho Cloud

はじめに

CTO の米内です。Flatt Security は、本日 2023 年 8 月 23 日、テック組織がクラウドのセキュリティを考える際の一歩目を支える SaaS 「Shisho Cloud」（シショウ クラウド） をリリースしました。

Shisho Cloud は、大雑把に言えば 「AWS/Google Cloud 上のリソースの設定がセキュリティ的に良さそうか、改善できそうかというのを検査してくれる製品」 です。 小難しい言い方をすると Cloud Security Posture Management（CSPM）の実現のための製品です。

我々がどんな背景で、どのような強みのサービスを提供するかが気になる方は、是非プレスリリースをご一読ください。

ただプレスリリースは、より広いオーディエンスに向けて書かれるという特性上、若干技術者の方には淡白に見えるかもしれません。手練の（セキュリティ）エンジニアであれば尚更です。 そんなあなたに耳よりな情報を一つ: Shisho Cloud には サービスのコア挙動がユーザーに Rego コードとして露出している、という技術的に面白い特性 があります。

例えば Shisho Cloud 上の全ての検出ロジックは、以下のような Rego コードとして提供されており、閲覧・編集ができるようになっています。

decisions[d] {
    # 各 AWS アカウントの…
    account := input.aws.accounts[_]

    # 各 S3 バケットが…
    bucket := account.s3.buckets[_]

    # バージョニング設定内で、MFA deletion を有効にしているかを確認し…
    allowed := versioning_needs_mfa(bucket.versioning)

    # Shisho Cloud に判定結果と証跡をレポートする
    d := shisho.decision.aws.s3.bucket_mfa_delete({
        "allowed": allowed,
        "subject": bucket.metadata.id,
        "payload": shisho.decision.aws.s3.bucket_mfa_delete_payload({"mfa_enabled": allowed}),
    })
}

versioning_needs_mfa(v) {
    v.status == "ENABLED"
    v.mfaDelete == "ENABLED"
} else = false

上述のような仕組みにより、「このタグがついていたら例外扱いする」「この命名規則に従っていたら緊急度を下げてレポートする」というようなカスタマイズが自分たちの基準 で行えるのです。 もちろん自社が有している固有のセキュリティポリシーを、上述のようなコードとして表現して検査を自動化することもできます。 これらは Shisho Cloud の強みの一つです。

そこで本記事では、この記事を訪れてくれた方の好奇心に応えるための副読本として、Shisho Cloud の根底にある技術的な設計思想のひとつである「セキュリティ SaaS をよりプログラマブルに」という点に焦点を当てて Shisho Cloud を紹介したいと思います。

本稿を通して Shisho Cloud というセキュリティプロダクトにより興味を持っていただけたら嬉しいです。 また、何らかの Developer SaaS/Platform の開発に取り組むチームにとっての良いケーススタディになることを祈っています。

Developer SaaS/Platform における「個別最適性」のためのアプローチ

まずは一般の技術者を取り巻く SaaS やプラットフォーム的サービス（本稿ではゆるく Developer SaaS/Platform と呼称することにします）に関する潮流を俯瞰してみましょう。

「普遍課題の解決」と「個別課題の解決」を同時に実現したい

異なるテック組織は異なるゴール・制約・業務プロセスを持ちます。 例えば EC 事業と FinTech 事業とでは、開発するソフトウェアに求められる信頼性は異なることでしょう。 開発・運用のプロセスに対する外部規制も異なります。 このような背景から「どの組織においてもベストな技術選定」なる銀の弾丸が存在しないのも自然なことです。

とはいえ Developer SaaS/Platform 提供者の視点では、より大きなマーケットに受け入れられる製品に仕上げたいのが常でしょう。 そのため、多くの提供者が 「可能な限り普遍的な製品を目指しつつも、それでいて多くのお客さんに高体験でフィットする製品を目指したい」 という悩みを常に抱えることになります。これこそがサービスを拡張・カスタマイズするための機能を提供するモチベーションです。

技術者向けだからこそのアプローチが存在する

先述のモチベーション自体は、非 Developer 向けの SaaS の世界でも共通のものです。 そのため解決策として、一般 B2B SaaS のカスタマイズ機能として「ノーコード的なエディタでワークフローを構築できる機能」「マーケットプレイスで提供されているプラグイン」を見かける機会は珍しくありません。公式 API の提供も一般的になってきました。

ここで、Developer SaaS/Platform の世界で「全員の課題解決と、誰かの課題解決をいかに両立するか」という問に向き合うと、これが興味深い側面を持つことに気が付きます。 「コード片や実行可能イメージを提供してもらうことによる拡張・カスタマイズ機能の提供」 という選択肢がより現実的になるから です。

技術者向けの場合、右側のアプローチが選択肢に入る

技術者向けの「個別課題の解決」のための機能例

より具体的なイメージを掴むために、いくつかの機能事例を Developer SaaS/Platform 特有のものに絞って紹介してみます。

DSL の提供・実行による機能の拡張・カスタマイズ可能性の提供

可視化・監視領域では、Domain-Specific Language（DSL）を用いてカスタマイズできる製品が少なくありません。 Grafana にしても Datadog にしても、様々なクエリ言語により、データを以下に集約して表示するかを規定できます。

Grafana + PromQL

この方面の機能は、外部にただ API を提供する形態と異なり、 ユーザーにランタイム・インフラを用意させない 点が特徴的です。それでいて製品の挙動を、再現可能性/容易性のような as Code 系技術の利点は残しつつ担保できています。

一方、DSL はユーザーの学習コストを要するのが課題です。その上、人口に膾炙したプログラミング言語に比べて、エディタ上でのサポートが充実していないのも頭を悩ませる点です。 とくに近年の Copilot を始めとした機械学習系テクノロジの恩恵を受けにくい点も、新規に生まれる DSL ほど留意せねばならないでしょう。

任意コード実行による拡張・カスタマイズ可能性の提供

DSL による機能拡張・カスタマイズの課題への解決として、近年はよりシンプルに、一般プログラミング言語に対する処理系を提供するような製品も少なくありません。 「データを保存・編集・削除できる箱」としての SaaS だけではなく、「データストア + データやイベントに最も "近い" 処理系としての SaaS + FaaS」 が新たに登場しつつある、と言い換えてもよいでしょう。

例えば Auth0 は Auth0 Hooks / Auth0 Rules として、長らくイベント（ユーザーのサインイン・サインアップ等）発生時の JavaScript 実行機能を提供してきました。 現在も Auth0 Actions として新たな FaaS 的基盤を提供し続けています。

Auth0 Actions

Developer SaaS/Platform というカテゴリに閉じずに考えると、Next generation Slack Platform も同じ志向を持ったプロダクトといえます。 同プロダクトは、主に Slack 上のイベントをトリガとして Slack に関する JavaScript/TypeScript コードを実行できるサーバレス基盤です。

The next-generation Slack platform へのデプロイ

この方面の機能は、ユーザーにランタイム・インフラを用意させない という、DSL による SaaS の拡張・カスタマイズ路線と同じ方向性を持ちます。 その上で、学習コストを低減し、既存の言語エコシステム（エディタやパッケージマネージャ）の恩恵を追加で獲得するのが特徴的です1。

なお拡張のためのプログラムは、必ずしもソースコードとして提供される必要はありません。 例えば WebAssembly はこのような用途で使いやすい可搬な単位かもしれませんね2。

Flatt Security のこれまでの歩みと現在地点

ここまで「ユーザーごとに最適な体験・個別の要件を実現するための機能例」であって、とりわけ Developer Platform/SaaS に特徴的なものを挙げてきました。 これらの例は、現代の技術者が安心して価値を生み出せる社会を目指す我々 Flatt Security にとって、大変重要なヒントです。

そこで我々は 「弊社の主たるスコープであるプロダクト組織・テック組織を取り巻くセキュリティサービスの体験は、各顧客にとって最適なのだろうか」 という問いに長らく向き合ってきました3。

この道中にある我々の現在地点が、本日正式リリースを迎えた Shisho Cloud（シショウ クラウド） です。

プロダクトセキュリティ領域における、個別の体験が損なわれている例

前提として、弊社はこれまで脆弱性診断事業や KENRO 事業（Web セキュリティに関する e-learning）を通して、多くのプロダクト開発・運用組織を支援してきました。 そんな各組織様と対話を続けていく中で、各組織ごとの課題が存在することを確かめながらも、共通の課題が見出されてきました。 その一つが 自社が理想とするセキュリティベースラインと、セキュリティ検査系プロダクトが用いるベースラインのズレ です。

自社の理想と検査系プロダクトのズレ

たいていセキュリティ検査系プロダクトを初めて使い始めるタイミングは、最大公約数的な形として、大量の検出事項が提示されます。 もっとも 検出事項の全てが組織にとって重要なものとはいえない ため、継続的な運用には「自社にとって重要な検査観点はどれか？」等の検討が不可欠です。 具体的には「このログ取得設定はマストとしよう」「この制限は厳しすぎるから止めよう」といった思考が求められることでしょう。

また、自社固有の観点（命名規則、タグポリシー、…）があれば、それも何かしらの形で継続的な検査を行いたくなる場合もあります。

しかし、こうして見えてくる自社にとって理想的なベースラインは、必ずしも現代のセキュリティ検査系プロダクトには反映できない のが課題です。 そもそも既存の検査は検査ロジックがブラックボックスである、新規の検査項目を追加するのは難しい、といったようにです。

セキュリティ検査をよりプログラマブルに ― Shisho Cloud での再設計の例

「セキュリティ検査をするソフトウェア」は、大雑把に言えば「データの取得・保持をするソフトウェア」と「データの検査をするソフトウェア」が融合したものです。 ここでの課題は「データの検査をするソフトウェア」のブラックボックス性とも言えます。

こう抽象化してみると、これまで例示してきた他製品の取り組みのうち Developer Platform/SaaS の SaaS + FaaS 的構造への転換がフィットしそうです。 そこで Shisho Cloud においては、実際に自社のセキュリティベースラインに沿ったセキュリティ検査を、プロダクト内でユーザーが自由に追加・更新・削除できる仕組みを提供しています。

Shisho Cloud 上でのポリシー管理（ワークフロー機能）

例: 既存の検査ロジックの変更

例えば Shisho Cloud 上の全ての検出ロジックは、以下のような GraphQL クエリと Rego コードの組として提供されています。 まず GraphQL クエリは「どんなデータを検査するか」を宣言的に定義します:

query {
  aws {
    accounts {
      s3 {
        buckets {
          metadata {
            id
          }
          versioning {
            mfaDelete
            status
          }
        }
      }
    }
  }
}

その上で、Rego コードは「GraphQL クエリで定義されたデータをどのように検査するか」を定義します:

decisions[d] {
    # 各 AWS アカウントの…
    account := input.aws.accounts[_]

    # 各 S3 バケットが…
    bucket := account.s3.buckets[_]

    # バージョニング設定内で、MFA deletion を有効にしているかを確認し…
    allowed := versioning_needs_mfa(bucket.versioning)

    # Shisho Cloud に判定結果と証跡をレポートする
    d := shisho.decision.aws.s3.bucket_mfa_delete({
        "allowed": allowed,
        "subject": bucket.metadata.id,
        "payload": shisho.decision.aws.s3.bucket_mfa_delete_payload({"mfa_enabled": allowed}),
    })
}

versioning_needs_mfa(v) {
    v.status == "ENABLED"
    v.mfaDelete == "ENABLED"
} else = false

このように定義された検査ルールは、実際に Shisho Cloud により適宜「実行」（= GraphQL クエリに従った API データの取得 + 取得データを用いた Rego コードの実行）されます。 勿論、検査の実行タイミングも、上記の検査ルールを束ねる以下のような構造の YAML ファイルを通して変更可能です:

version: 0.1.0

id: "prebundle-aws-s3"
name: "Prebundle: Review AWS S3 posture"

triggers:
  schedule:
    - cron: "0 */1 * * *"

jobs:
  # snipped...
  - id: bucket-mfa-delete
    name: Review the status of MFA delete
    decide:
      rego: !include bucket-mfa-delete/decide.rego
      input:
        schema: !include bucket-mfa-delete/decide.graphql
  # snipped...

つまりユーザー視点では、Shisho Cloud が検査する全てのセキュリティ検査の観点やロジックが閲覧可能であり、かつ編集可能であるということです。 なんならこちらの例のように、弊社が提供しているポリシーは GitHub 上でも閲覧可能です。 GitHub Actions から Shisho Cloud に検査ルールを継続的デプロイ（CD）することもできます。

GitHub 上で管理されたポリシー（イメージ）

このような機能により、 「特定の AWS アカウントに関してのみ判定を変えたい」「特定のタグが付いていたら緊急度を上げてレポートしたい」 というような個別最適ニーズも、ポリシーコードの変更により実現することが出来ることになります。

Shisho Cloud は現時点ではおよそ CSPM を実現できる製品としての機能を有していますが、これは既存のセキュリティ製品の SaaS + FaaS 的モデルによる再設計 ― あるいはプログラマブルな形への再設計をしたものと言って差し支えないでしょう。

例: 新たな検査ロジックの追加

先述のような GraphQL クエリと Rego ポリシーは、当然ユーザーが自由に記述することもできます。 この場合 Shisho Cloud はその定義に従い、データを各所から集めてきて、ポリシーを実行する FaaS として機能します。

例えば もし自社 AWS 環境上のリソースが、あるルールを満たしているかを Shisho Cloud で検査したくなったとしましょう。 この場合、(1) おもむろにお好きなエディタを開いて、それを (2) shishoctl で Shisho Cloud にデプロイするだけで仕事が完了します:

$ vscode ./policy.yaml # (1)
$ shishoctl workflow apply -f ./policy.yaml # (2)

これまで Docker は Build. Ship. Run. を、Vercel は Develop. Preview. Ship. を実現してきました。 他にも複雑だった工程、トイルの大きな工程を 3 単語ほどに圧縮してきた偉大なプロダクトがこの世界には多数存在していますが、彼らに倣うとすれば、Shisho Cloud は Write. Ship. Enforce. を実現するためのプロダクトといえます。

そして、セキュリティ SaaS をよりプログラマブルに

さて、上述のように、Shisho Cloud は個別最適の追求のために 全ての検査項目をプログラマブルにする ことに取り組んできました。 実はこの Shisho Cloud は、通知系のコントロールを初めとして、これ以外の点に関しても同様なコンセプト「セキュリティ SaaS をよりプログラマブルに」 というコンセプトに従って作られています。

また、Shisho Cloud では現在、検査対象データのソースとして現在 AWS/Google Cloud に加え GitHub API が利用できます。 このデータソースは今後も拡充予定なので4、この点において、Shisho Cloud の進展がおよそ様々なセキュリティ SaaS のプログラマブルな置換を実現していく と言っても過言ではありません。

「プログラマブルに再設計」でむしろ体験を損なわないために

なおこの挑戦にあたっては、以下の 2 点は合わせて強く意識しています:

  • (A) 「カスタマイズなし（Zero-configuration）でも好体験」は大前提とする
  • (B) 個別最適が不要な点は積極的に自社で磨き込む

(A) に関しては言うまでもないでしょう。Flatt Security は「セキュリティの力で信頼をつなげ、クリエイティブな社会を実現する」というビジョンを掲げる企業です。 あくまで我々の本願は、我々のユーザーの不安やリスクを取り除き、前進しやすくすることにありますから、可能な限り小さな工数で最適なものを提供するのは今も昔も変わらない目標です。

また (B) に関しても、Flatt Securityが取り組むほうが、大多数のユーザーに最適なメリットをもたらすことができる点が多々あるのは明らかです。 例えば検出結果の可視化や連携情報のシークレット管理、Shisho Cloud 上で管理できるサービスカバレッジ、業界標準（CIS Benchmark 等）への対応は、我々が担うほうが効率のよい領域です。 これを踏まえて、当該領域には積極的にリソースを投じています。

最後に

本記事では Shisho Cloud の正式リリースによせて、昨今の Developer SaaS/Platform に見られる拡張・カスタマイズ可能性に関する潮流と、Shisho Cloud での取り組みを紹介しました。 冒頭で述べた通り、これはあくまで副読本的立ち位置の文章ですから、Shisho Cloud という製品の嬉しさや使い方はご紹介しませんでしたが、この点が気になる方は是非 プロダクト LP からお問い合わせください！

また、本日の正式リリースは、Flatt Security や Shisho Cloud にとってスタートラインに過ぎません。この 「セキュリティ SaaS をよりプログラマブルに」 というコンセプトと合わせて、およそ 「分散したセキュリティデータ・ソリューションのリバンドル」 のような本稿で言及しきれなかった大テーマにも向き合っていきたいと考えています。ご興味のある方は是非 @flatt_security 等での発信を引き続きウォッチいただけると嬉しいです。

  1. 上述の例まで自由度が高い機能になってくると、Near-data processing（NDP）や Edge computing 的なところと発想は近いように見えてきますね。↩
  2. 一応 WebAssembly バイナリを用いてポリシー記述ができるようにする、というのも提供可能な状態まで来ているのですが、UX がそこまで高くなかったので一旦ステイしています。↩
  3. 最近リリースした 『Flatt Security の脆弱性診断において「ソースコード診断を無料付帯する」方針』 は、プロフェッショナルサービス事業における一つのアンサーといえます。↩
  4. その他、現在外部からのイベントデータ（Cloud Events 等）や、外部 REST/GraphQL API からの検査時の動的なデータ取り込みについても可能性を模索しているところです。↩