2024-11-21

SIGQ Cloud Linkerを支える技術：その1 概要編

こんにちは。SIGQ Cloud Linkerというセキュアな書類共有サービスを開発しているアーリースタートアップ、SIGQのリードエンジニアをしているBrown[1-3]です。

ストーリー性がよく分かりませんが、それはさておき、今回から何回かに分けて、SIGQ Cloud Linkerを支える技術をご紹介していきます。

本編はその導入で、概要をご説明します。

技術ブログを書いてばかりで、実はまだ公式のプレスリリースは1度も出していない

SIGQ Cloud Linkerとは

SIGQ Cloud Linkerは、バックエンドにGo、フロントエンドにReactを採用し、GCPのフルクラウド環境上で稼働する次世代のセキュア書類共有ツールです。GCPの柔軟でスケーラブルなインフラを最大限に活用し、Cloudflare WAFによる高度なWebアプリケーションファイアウォールを通じてセキュリティを強化しています。セキュリティ対策は、マルチテナント環境においてユーザーのデータ保護を最優先に、各レイヤーで堅牢なセキュリティ対策を施しています。

　また、SIGQ Cloud Linkerに将来的に導入するように、データのストリームプロセスエンジンと組み合わせて可能できる機械学習モデルの研究開発を行っています。この機械学習モデルは、膨大なデータを解析し、高精度の予測とリスク管理を可能にするために設計されており、将来的には、書類管理の効率化やセキュリティリスクの自動検出機能など、従来のシステムにはないインテリジェントな機能をご提供できる見込みです。

SIGQ Cloud Linkerの開発者の人数

Webサービスでは一般に、シード期でVCからエクイティで資金調達をしたり、金融機関からデットで資金集めを行なった上で、数名の開発チームを作ってサービスを出していくことが一般的だと思うのですが、弊社の本プロダクトでは、レポジトリを作ってからリリースに至るまで私のコミットしか入っていません。つまり、企画やプロダクトマネジメントから、全ての開発において、私しか関与していません。

　直近では、よりリリース前のQAをしっかりと行なっていくために、業務委託のメンバーに参画いただき、バグ出しやユーザビリティテスティングについて協力にサポートいただいていますが、開発はこのブログを書いている時点では私のコミットしか入っていませんw

　というのも、そもそものスタートが趣味の個人開発からスタートしたプロダクトであり、また、学生時代に一度友人と起業して揉めてしまった経験（当時、大変申し訳ございませんでした）から、次何かをやるなら1人でやろうと決めていたので、とりあえず1人でやってきました。

SIGQ Cloud Linkerのメインの構成

前置きが長くなりましたが、主にCloud Linkerは以下の構成で動いています。Webサービスとしては特に目新しいことはなく、それっぽい構成になっています。

　以下に書いてない内容だと、WAFに似た動きをするHTTPリクエストを通すか通さないかを裏側でハンドリングする軽量な機械学習モデルを作りたくて、SVM（Support Vector Machine）っぽいMLモデルの開発をひっそりやっています。現在はそのMLモデルのformulationを行なっている段階で、そっちはそっちでツールとしては色々と使おうとしていますが、現段階ではCloud Linkerを支えるツールはこんな感じです。

フロント

React, Tailwind CSS + Firebase Hosting

認証

Firebase Auth

バックエンド

httpサーバーにginを薄く使っただけで、あとはスクラッチで書いているGolang

インフラ

Cloud Run, Cloud Run Job, PubSub, Eventarc, MongoDB Atlas, Cloudflare

MongoDBに繋ぎに行くところでIPを特定のものに絞るために、Cloud RunはVPCの中で動かしていて、egressは特定のIPから出ていくようにしています。

監視系

Datadog, Atlassian status page

今後のブログの展開

今回は導入部分しか書いておらず、中身はさらっとしています。今後なぜこの技術選定になっているのかを、エンジニアとしてのスキルセット面や興味だけではなく、コストや今後の開発も考えた技術経営の観点からご紹介していく見込みです。ぜひサブスクライブしてご覧ください。

終わりに

SIGQではCloud Linker (https://sigq.jp/)を使っていただける方を絶賛募集中です。昨日、一般向けに新規登録導線をオープンしました。早く登録いただいた方には、アーリーサインアップ特典で、何らか特典をご用意したいと思っています。（詳細未定）

References

[1] あちこちの組織に属しており、インターネット上で筆者関連情報が散見されるが、本法人とはいずれも無関係

[2] GitHub Account: 3150

[3] X (Twitter): brownjpn

2024-11-20

アーリースタートアップがDatadogを部分的に使う方法

こんにちは。SIGQ Cloud Linkerというセキュアな書類共有サービスを開発しているアーリースタートアップ、SIGQのリードエンジニアをしているBrown[1-2]です。 SIGQではまだサービスを正式リリース前にもかかわらず、Datadogをすでに導入して、仮説検証や、プライベートベータの提供を行っています。

スタートアップにおける懐事情と監視ツール選定

DatadogはAPM（Application Performance Monitoring）や、インシデント監視など、アプリケーションの信頼性向上や、開発者体験をよくする様々な便利な機能を提供しており、多くのスタートアップやエンタープライズ企業から使われています。

　これらの機能は使いこなすと非常に有用なツールである一方で、そもそもとにかく早く機能を作って早く世の中に出していくことが最優先なアーリースタートアップの開発現場においては、サービスの信頼性向上よりも、事業として一定のリスクを許容することで、エラートラッキングや外形監視などの優先度が下がっている場合が多いのではないでしょうか。

　また、エンジニアの工数的な面だけではなく、アーリースタートアップでは、外部からの資金調達を行なっている場合であっても、バーンレートを下げるために、なるべく無料のツールを駆使して、創意工夫のもと開発を行なっておられるのではないでしょうか。このような場面において、なかなか外形監視ツールにお金を払うという意思決定はなかなかしにくいかなとおもいます。

SIGQで使っているDatadogの機能

Datadogはいろいろできますが、「サービス全部の機能を使って月に50ドル」のような課金体系ではなく、例えばAPMのホストあたりに38.75ドルといったように、機能毎 & 従量課金です。

www.datadoghq.com

SIGQでは、なるべく安く、しかしやりたいことは全部Datadogで済ませるために、以下の機能を使用しています。

RUM（Real User Monitoring）
Monitoring
Logs
Error Tracking
Synthetics Testing

なぜSIGQがサービスのパブリックリリース前からわざわざ有料の監視ツールを導入しているのか

現在のメインの目的は上記に挙げたツールを使い、以下の項目を監視することです。

エラー
重要な機能が正常に機能しているか
各種メトリクスは正常か

また、上記のような一般的な使い方に加え、プロダクトマネージャーの視点でプライベートベータの状態で体験で使っていただいている人が画面上でどのような動きをしているかをRUMで見ています。 そうです。RUMこそが今一番使いたい機能なのです。

なぜRUMなのか

www.datadoghq.com

Webサービスのベータ版では、免責事項で「ベータ版なので、正しく動作しないことがあります」「機能に予告なく破壊的変更を加えることがあります」といった免責事項を利用規約に盛り込むことが多いと思うのですが、それはあくまで規約上での免責事項なのであって、「じゃあ機能がちゃんと動かなくてもいいよね」というわけにはいきません。

　すでに成熟したプロダクトであれば、多少のエラーがでたり、多少使いにくくても、使い慣れたユーザーがすぐにサービスから退会ということはないのではないかと思うのですが、アーリースタートアップのベータ版のサービスでは、そもそもサービス自体がその時点ではユーザーにとって必要不可欠なものではない場合が多く、エラーが多く出たり、サービスが使いにくいと、簡単にユーザーの離脱に繋がってしまうと思います。

　そこで、SIGQでは実際に使ってもらっているユーザーがサービス上でどのような動きをしているのかの把握をSession Replayを使い観察し、より良いユーザー体験は何かということを考えたり、混乱してそうな場所はどこかということを把握して、すぐに改善を加えるようにしています。また、Session Replayではコンソールエラーも紐づけて見ることができるので、もしエラーが出た際には、そのユーザーから申告が入る前に再現方法を把握して直すといったことも可能です。

　このようにしてみると、DatadogのRUMはエンジニアが信頼性向上などの名目で使うだけではなく、プロダクトマネージャーや経営者がユーザーと間接的に対話できるツールでもあるのです。

終わりに

SIGQではCloud Linker (https://sigq.jp/)を使っていただける方を絶賛募集中です。ついさっき、一般向けに新規登録導線をオープンしました。早く登録いただいた方には、アーリーサインアップ特典で、何らか特典をご用意したいと思っています。（詳細未定）

References

[1] あちこちの組織に属しており、インターネット上で筆者関連情報が散見されるが、本法人とはいずれも無関係

2024-11-19

WAF導入環境でDatadogのBrowser Testingを使用する方法

こんにちは。SIGQ Cloud Linkerというセキュアな書類共有サービスを開発しているアーリースタートアップ、SIGQのリードエンジニアをしているBrown[1-2]です。

SIGQではDatadogのBrowser Testingを使用して、ブラウザ上で重要な機能が適切に動作するかの検証を自動で行っています。

Datadogに限らず、他社のBrowser Testingも含め、これらは非常に有用なツールである一方で、ログインの認証が求められたり、WAFなどのセキュリティレイヤーを導入していると、公式ドキュメント通りに設定しても、様々な原因でちゃんと動かないことがあります。本日はDatadogのBrowser TestingをWAF（Web Application Firewall）が入っているWebサービスに導入する際の困ったことと、解決方法を共有します。

DatadogのBrowser Testingとは

Datadogのブラウザテストは、ウェブアプリケーションのユーザーの行動をシミュレートし、定期的にその動作を検証する機能です。これにより、アプリケーションの可用性やパフォーマンスを継続的に監視し、ユーザーが遭遇する可能性のある問題を早期に検出できます。

主な特徴

シナリオベースのテスト: DatadogのRUM （Real User Monitoring）でユーザーの操作手順を記録し、複雑なシナリオを自動化して再現できます。
多様な環境での実行: 異なるブラウザやデバイス、地理的なロケーションからテストを実行し、さまざまなユーザー環境での動作を確認できます。

docs.datadoghq.com

WAF導入環境でDatadogを導入すると困ること

SIGQではWAFにCloudflareの有料版WAFを導入して、より安全なアプリケーションをご提供できるようにしています。

www.cloudflare.com

Cloudflare WAFではBot managementの機能がついているため、Botっぽいリクエストを弾く設定を行うことができますが、一方で、この設定によりDatadogのBrowser Testingからサイトにアクセスした時に弾かれてしまうことがあります。ちゃんとWAFが機能してるのでヨシッとはできず、Browser Testingの観点では困った問題で、もしかしたらこのブログに辿り着いた方は「よくわかんないからBrowser Testingを入れるのを諦めようかな。。。」となっておられる方もいるのではないでしょうか。

実際にDatadogのBrowser TestingがCloudflare WAFに弾かれた図

／(^o^)＼ﾅﾝﾃｺｯﾀｲ

WAFにBrowser TestingがBlockされるのを防ぐ方法

SIGQではFirebase Hostingをオリジンにして、WAFとDNSだけCloudflareを使用しています。そのため、WAFにブロックされるのを防ぐためには、以下の2つの方法が挙げられます。

特定のリクエストヘッダーがある場合のみCloudflareのWAFポリシーをIgnoreする設定を入れる
特定のパスだけCloudflareのWAFポリシーをIgnoreする設定を入れる
Browser TestingからはFirebase Hosting のURLを直指定してWAFを通さないようにする

今回取ったワークアラウンド

今回は1の「特定のリクエストだけCloudflareのWAFポリシーをIgnoreする設定を入れる」という設定をCloudflare側で設定しました。具体的にはリクエストヘッダーに特定のキーがセットされていれば、そのリクエストはWAFを適用しないという方法です。

CloudflareでのWAF設定

このルールは「すべてのリクエストにWAFのルールを適用するが、リクエストヘッダーに特定のキーがセットされていれば、そのリクエストは無視する」という方法です。

後述しますが、この方法では折角WAFを導入しているのに、その例外でWAFのルールが適用されないリクエストヘッダーを無闇に外部に公開すると、そのリクエストヘッダーを悪意のある攻撃者がセットしてリクエストしてきた際にWAFで防げないので、以下のスクショではマスクしています。

Datadogでの設定

Browser Testingの「Advanced Options」から、先ほどcloudflareでセットしたキーをリクエストヘッダーにセットします。

今回取ったワークアラウンドの理由

まず、このてのワークアラウンドを入れる際には、サービスに悪い副作用を極力及ぼさないようにする必要があります。例えば、Browser Testingでサービスの信頼性を向上させようとした結果、うまく動かなかったワークアラウンドでアプリケーションコードのCORSの設定をザルにしたりしてセキュリティホールを開けては本末転倒です。

そこで本提案手法では「リクエストヘッダーに特定のキーがセットされていれば、そのリクエストは無視する」というWAFの設定を入れました。この方法では、アプリケーションコードを変更する必要がなく、WAF側の設定だけを変更するだけであり、かつ、そのヘッダーがあってもなくても、アプリケーションの動作自体には影響が出ないので、アプリケーションに変な副作用は及ぼしにくいです。

ここで、前述した「そのリクエストヘッダーを悪意のある攻撃者がセットしてリクエストしてきた際にWAFで防げない」という点は副作用としてあげられますが、このリクエストヘッダーはパブリックな場に貼るものでもないので、外に漏れにくいです。また、定期的にローテートするようにすれば、リスクは軽減できると思っています。

他の選択肢

次に、他の選択肢に関して見ていきます。

特定のパスだけCloudflareのWAFポリシーをIgnoreする設定を入れる

この場合には、そのパスだけWAFのポリシーがかからなくなるので、そのパスがBotによる攻撃を受けた時に、他のパスに比べて脆弱になりかねません。また、他のパスをテストしたい時には都度パスを加える必要があるので、煩雑です。

Browser TestingからはFirebase Hosting のURLを直指定してWAFを通さないようにする

前提として、特定のドメインからのリクエストのみをバックエンドサーバーのCORSのAllowOriginの設定では許可するようにしていますが、この方法では、Firebase HostingのURLをブラウザテストのためだけにCORSの設定に追加しなければなりません。つまり、本来CORSのAllowOriginで特定のドメインからのアクセスだけにしたいのに、テストのためだけに他のドメインもCORSのAllowOriginに加えないといけないため、微妙です。

最後に

SIGQではCloud Linker (https://sigq.jp/)を使っていただける方を絶賛募集中です。まだパブリックには新規登録導線を開けていませんが、利用ご希望の方はぜひプロダクトページの右下からサポートチケットを起票いただいて、利用希望の旨を教えてください。アーリーサインアップ特典で、何らか特典をご用意したいと思っています。（詳細未定）

References

[1] あちこちの組織に属しており、インターネット上で筆者関連情報が散見されるが、本法人とはいずれも無関係

[2] GitHub Account: https://github.com/3150

2024-11-17

SIGQのエンジニアブログを開設しました

SIGQのエンジニアブログを開設しました。

SIGQ Cloud Linkerというセキュアな書類共有サービスを開発しているアーリースタートアップ、SIGQのリードエンジニアをしているBrownです [4-5]。

SIGQのご紹介

地域と共に、持続可能な未来へ
日本では都心一極集中が進む中 [1-2]、地方には伝統や名産品、自然など、世界に誇れる豊かな魅力が数多く存在しています。私たちは、テクノロジーの力を駆使して、こうした地域の価値を国内外に広め、地域経済の活性化に貢献するお手伝いをしています。

会社情報：https://company.sigq.jp

サービス紹介

SIGQではSIGQ Cloud Linkerというマルウェアスキャン [3]も備えたセキュアな書類共有サービスの開発を行っており、近日パブリックベータ版をリリース予定です。

サービスURL：https://sigq.jp

SIGQ Cloud Linkerの特徴

今後のブログの展望

今後のブログでは、SIGQ Cloud Linkerの技術的な詳細、インフラ構築の工夫やセキュリティの強化に関する取り組み、そして機械学習モデル開発の背景や技術選定の意図などについても深く掘り下げて紹介していきます。私たちの技術的な挑戦とSIGQ Cloud Linkerの魅力を、エンジニアリング視点から共有してまいります。

---

References

[1] 国土交通省. (2020). 「第2章交通政策の現状と課題」. 令和元年度国土交通白書. https://www.mlit.go.jp/hakusyo/mlit/r01/hakusho/r02/html/n1112000.html

[2] 地域未来研究会. (2022). 「地域未来報告No.8473」. https://chikouken.org/report/report_cat01/8473/

[3] Davide Maiorca, Battista Biggio, and Giorgio Giacinto. 2019. Towards Adversarial Malware Detection: Lessons Learned from PDF-based Attacks. ACM Comput. Surv. 52, 4, Article 78 (July 2020), 36 pages. https://doi.org/10.1145/3332184

[4] あちこちの組織に属しており、インターネット上で筆者関連情報が散見されるが、本法人とはいずれも無関係

[5] GitHub Account: https://github.com/3150