【ITニュース解説】Week-6, 7, 8

システムエンジニアを目指す初心者にとって、日々の開発作業は単に新しい機能を作るだけではないということを、今回の記事はよく示している。Hiero (LF Decentralized Trust) Heka Identity PlatformにおけるHeka Auth Serviceの開発状況を伝えるもので、GPG Contributor Verification FlowとGitHub OAuth Bindingという二つの新機能の実装を通じて、ソフトウェアの設計（アーキテクチャ）、安全性（セキュリティ）、複数の処理の並行実行（並行処理）、そして開発からリリースまでの自動化プロセス（CIパイプライン）といった、より深いエンジニアリングの課題に取り組んだ様子が語られている。

まず、アーキテクチャの境界の考え方は非常に重要だ。これは、ソフトウェアを構成する各部品やサービスが、それぞれ明確な役割を持ち、その役割以外の部分には干渉しないように設計する原則を指す。今回のプロジェクトでは、GPG認証のロジックやデータベースの接続部分が、当初誤ってheka-identity-serviceという別のサービスに混入してしまっていた。しかし、コードレビューのフィードバックを受け、それらの不適切な要素をheka-identity-serviceから完全に削除し、GitHub OAuthとGPGチャレンジの全フローをheka-auth-serviceという認証専門のサービス内に集約させた。これは、マイクロサービスという、機能を細かく分割して独立したサービスとして構築するアーキテクチャにおいて特に重要な考え方である。これにより、identityサービスは「誰がどのように認証されたか」を知る必要がなくなり、authサービスが認証を保証することだけを信頼すればよい、という厳密なサービス間の境界が保たれる。また、データベースのスキーマ（構造）をコードから自動生成する「コードファースト」のアプローチを採用し、MikroORMというツールを使って認証サービス内でクリーンなデータベースマイグレーション（変更履歴）を管理している。

次に、セキュリティの強化は、外部サービスと連携するシステムでは特に気を配るべき点だ。公開されたGPGキーをGitHubのような外部プロバイダーから取得する際には、悪意のある攻撃に対する防御策を徹底する必要がある。

一つ目の対策は、SSRF（Server-Side Request Forgery）攻撃の防止である。SSRFとは、攻撃者がサーバーに不正なリクエストを送信させ、意図しない外部システムへのアクセスや内部情報へのアクセスを試みる攻撃だ。当初、サービスはリクエストからGitHubのユーザー名を受け取り、その情報を使ってGPGキーを取得するためのURLを生成していたが、これではユーザー名に不正な文字（例えば、ディレクトリ階層を遡る../のような文字）を挿入されることで、サーバーが本来アクセスすべきではないURLにアクセスしてしまう危険性があった。この問題を解決するため、GitHubのユーザー名が厳格な正規表現のパターン（GITHUB_USERNAME_PATTERN）に合致するかを検証することで、不正な文字列の挿入を防ぐ対策が施された。

二つ目は、JWT（JSON Web Token）を信頼し、クライアントからの入力を直接信用しないという原則だ。以前はユーザーが提供するユーザー名を信頼して処理を行っていたが、これはユーザーが情報を偽装する可能性をはらんでいた。そこで、チャレンジリクエストのエンドポイントを完全に認証された状態とし、ユーザーから送られてくる安全なJWTトークンをデコードして、そこに含まれるユーザー固有のwalletIdを抽出し、データベースに登録されているそのユーザーの検証済みGitHubバインディング（紐付け情報）を検索するように変更された。これにより、ユーザー自身が提供する情報を信用するのではなく、サーバー側で安全性が保証された情報のみを使用するようになった。

三つ目は、ペイロード乱用（Denial of Service; DoS攻撃）の防止である。暗号処理を行うエンドポイントは、大量のデータ（ペイロード）を送りつけられることでサービスが過負荷になり、機能停止に陥るDoS攻撃の標的になりやすい。これに対処するため、GPG署名データを送るためのデータ転送オブジェクト（DTO）に@MaxLengthというバリデーション（入力値の検証）を追加し、送信可能なデータの最大サイズを制限することで、大量の不正なデータによる攻撃を防ぐ。

四つ目は、**ログのサニタイズ（無害化）**である。アプリケーションのログファイルに、ユーザーが制御できる入力（例えば、復号された署名テキストの生データ）をそのまま書き込んでしまうと、ログインジェクションという攻撃につながる可能性がある。これは、ログに不正なスクリプトなどを挿入し、ログを閲覧するシステムや担当者に被害を与える攻撃だ。これを防ぐため、呼び出し元が制御する入力は、アプリケーションのログに決して書き込まれないように処理が施された。

さらに、並行処理の課題と「Burn-Before-Verify」パターンの導入も注目すべき点だ。GPGチャレンジでは、一度しか使用できない暗号学的な値である「ノンス」が使われる。ここで、もし攻撃者が二つの全く同じ検証リクエストをほぼ同じタイミングで送信した場合、「レースコンディション」という問題が発生する可能性がある。これは、複数の処理が同時に同じデータにアクセスし、予期しない結果を引き起こす状態だ。もし単純に「チャレンジがすでに使用済みか？」をチェックするだけでは、二つのリクエストがデータベースから「まだ使用されていない」という情報を同時に読み取ってしまい、どちらのリクエストも有効なものとして処理を進めてしまう危険性があった。

この問題の解決策として、「Burn-Before-Verify（検証する前に焼却する）」というパターンが実装された。これは、サービスがネットワーク通信や暗号検証などの時間のかかる処理を行う前に、まずデータベースに対して「このチャレンジを『使用済み』にする。ただし、まだ使用されていなかった場合に限る」という更新クエリを原子的に（途中で中断されない形で）実行するというものだ。具体的には、MikroORMのnativeUpdate機能を使ってUPDATE gpg_challenges SET consumed = true WHERE id = ? AND consumed = falseというSQL文が実行される。データベースは、同時に発生した複数の更新リクエストに対して、行レベルロッキングという仕組みで一貫性を保つ。これにより、最初に更新リクエストが成功した一つだけが指定された行を「使用済み」に更新でき、他のリクエストは「0行が更新された」という結果を受け取る。この結果を判断することで、サービスは即座に二重のリクエスト（リプレイ攻撃）をブロックできる。これは、シンプルでありながら非常に堅牢な解決策である。

最後に、CIパイプラインの課題とSnyk、推移的依存関係への対応も語られている。CI（Continuous Integration）パイプラインは、コードの変更がリポジトリに統合されるたびに自動的にテストやビルドを行う一連のプロセスであり、ソフトウェアの品質を継続的に保つために不可欠なものだ。今回のケースでは、Snykというセキュリティスキャナーが、ビルドの失敗を引き起こす低深刻度の脆弱性アラートを突然発した。この問題の原因究明は難航した。なぜなら、脆弱性は開発者が直接書いたコードにあるのではなく、「推移的依存関係」と呼ばれる、自分のプロジェクトが依存しているライブラリが、さらに別の古いライブラリに依存しているという複雑な状況によって引き起こされていたからだ。具体的には、express@5が、古くて脆弱なバージョンのbody-parser@2.2.2を間接的に引き込んでいた。

この問題を解決するために、開発者は一時的なロックファイル（依存関係のバージョンを固定するファイル）の修正ではなく、よりクリーンな方法を選択した。それは、heka-auth-service/package.jsonファイルに"body-parser": "^2.3.0"と明示的に宣言し、脆弱性が修正された新しいバージョンを強制的に使用させるという方法だ。これにより、Expressの要求と最新のセキュリティパッチが両立し、Snykによるセキュリティチェックをクリアすることができた。また、Gitの履歴が完全にクリーンであり、すべてのコミットがLF Decentralized Trustによって強制されるDCO（Developer Certificate of Origin）に準拠するよう、git commit -sを使って署名されていることも確認された。

今回の経験は、新しい機能を開発すること自体は仕事の20%に過ぎず、残りの80%は、コードの設計、複数処理の制御、システムの安全性確保、そしてインフラストラクチャの管理といった、より包括的なエンジニアリングの側面にあることを強く示している。Heka Auth Serviceは、これらの深い取り組みを通じて、堅牢で信頼性の高いサービスへと進化している。