プロダクトをつくる研究開発組織LayerX Labsにおける技術選定の軸

LayerX LabsのOsuke（@zoom_zoomzo）です！今回の記事では、僕自身LayerX創業当初から研究開発をメインに取り組んできたこともあるので、Labsにおける技術選定や設計を考える上での軸やその具体例について紹介したいと思います。

f:id:osuketh:20210430103200p:plain

LayerX Labsにおける技術選定の軸

まずはじめにLayerX Labsについて簡単に紹介すると、「Labs」とついているようにLayerXにおける研究開発部署にあたるチームです。アカデミックに成果を出す基礎研究などを目的としているというよりも、あくまで「プロダクト」の開発を中心に取り組み、数年スパンのより長期的な目線で先端技術にベッドしていくことでこれまで解けなかった業界課題の解決を目指しています。

具体的には、Anonifyというオープンソースの秘匿化モジュールを開発し、個人情報などの機密性の高いデータの保護や秘匿性と透明性を両立するインターネット投票などのプロダクト開発に取り組んでいます。

github.com

このような背景で研究開発としての先端技術への投資とプロダクト開発としてのサービス提供を両立する技術選定・設計をしていることがLabsの特徴です。例えば、今現在の開発生産性・スピードも重要ですが、将来的に強みとなる技術的アセットが積み上がることやさまざまな業務にプロダクトとしてカスタマイズ可能となるような拡張可能性も重要視しています。

また、活用事例が少なく不確実性の高い技術を多く扱うことになるので、十分にテストケースを備え、負荷検証などの検証も早い段階から実施しています。一方、我々のコアではない技術は積極的に既存のサービス・ツールを利用しています。

Labsにおける技術選定や設計に関して、いくつか具体例をあげてみます。

言語選定： Rust

Anonifyでは、秘匿性と検証可能性をハードウェアレベルで実現するためにIntel SGXと呼ばれるプロセッサのセキュリティ機能（Trusted Execution Environment (TEE))を用いています。

これに対応するメジャーなSDKがそもそもRustかC++に限られます。（最近ではさまざまな言語で開発できるようなLibrary OSタイプのSDKを開発するプロジェクトも増えてきています。）また、言語仕様が多く比較的学習コストは高くなってしまいますが、Intel SGXのセキュアな保護領域で実行されるコードベースでは、メモリ安全性やシステムプログラミングに適しているという観点で非常に適しています。

tech.layerx.co.jp

インフラ選定・設計：Azure・AKS

2021年3月にAzure Kubernetes Service(AKS)上のConfidential ComputingノードがGAしており、Anonifyはこの上でインフラを構築しています。

Intel SGXのようなプロセッサレベルのセキュリティ機能をクラウド文脈で活用することは「Confidential Computing」というワードでよく取り上げられ、2020~2021年にかけて、AWSやGCPを初め多くの主要パブリッククラウドでTEEを利用することが可能になりました。

参考：

その中でも、AzureではIntel SGXやAMD SEV-SNPなどのTEEを活用したサービスを多く展開しています。将来的には、Anonifyのマルチクラウド化もロードマップにありますが、現時点ではIntel SGXを想定して開発を進めており、その相性の良さからAzureを選定しています。

なぜAKSか

AKSは、Azureにおけるマネージドなkubernetesクラスタサービスで、AWSのEKSやGCPのGKEに相当します。Anonifyのサービス的には小規模であるものの以下のようにデプロイメント・コンテナ管理が複雑になります。

コンテナごとのデプロイ順序： AnonifyではTEE上で複数種類のコンテナが連携して動きますが、それぞれを適切な順序でデプロイするようにコントロールする必要があります。
自動リカバリ：Anonifyは、アーキテクチャの種類によっては、TEEの隔離保護されたメモリ領域でin-memory databaseのように働くこともあります。この際、コンテナやVMが落ちてしまった場合、自動で復旧し暗号化されたデータの永続化レイヤーから適切にTEEへデータを復元する必要があります。
メモリリソース考慮してコンテナをスケジューリング：AnonifyではTEE（物理マシン）の限られたメモリリソースを考慮して適切にコンテナを配置する必要があります。Intel SGXを用いている以上、VM上で動いていようとコンテナ上で動いていようとkubernetesでオーケストレーションされていようと物理マシンを意識して開発することになります。例えば、複数コンテナが同じIntel SGXに対応した物理マシン上で動いているとします。Intel SGXの隔離保護領域のメモリは非常に制限された環境（SGXv1だと100MiB前後）であり、複数コンテナを動かすとこの限られたメモリを共有して使うことになります。（厳密には、暗号化されたメモリページとして100MiB以上使うことが可能ですが数十〜数百倍オーダーのオーバーヘッドがかかります。）このように、複数のコンテナを同一マシン上で動かすことが適していないケースも考えられます。
クラウド非依存：Anonifyを活用してさまざまなユースケースでプライバシー保護などのソリューションを提供していることから、将来的にさまざまなクラウド環境にデプロイ可能であることが理想です。クラウドに依存せず抽象化された構成管理ができている必要があります。

このような技術的要件の中で、Intel SGXを扱える環境ということでAKSのConfidnetial Computingノードを選定しています。研究開発組織であるもののプロダクトを開発し本番環境に耐えうるサービスの可用性や信頼性も考慮し、複雑性への対処と技術の再利用性の観点からサービスやチームとして小規模である現段階からAKSを活用することが適切であると判断しています。

ちなみに、AKSのConfidential Computingノードでは、ノードがSGX環境のDCsv2シリーズであり、Intel SGX用のkubernetes device pluginを用いてそれぞれのPodがノードの /dev/sgx/enclave や /dev/sgx/provision を認識できるようにしています。これにより、AKS上でハードウェアレベルの機密性に優れたワークロードを実現しています。

プロトコルアーキテクチャ設計

Anonifyにおけるアーキテクチャ設計を考える上で一番の情報源は論文です。例えば、TEE自体セキュリティに関する論文、TEEを応用することで既存システムのプライバシーやセキュリティを向上させる内容の論文、他にも暗号や分散システムなど幅広い要素技術を考慮に入れる必要があります。

アーキテクチャ自体がまずベストプラクティス化されていないので、理論的な側面からAnonifyの文脈に照らし合わせたときの適切なアーキテクチャや要素技術に落とし込んでいきます。ただ理論的には可能であることと、実際に実装可能であることさらに本番環境にプロダクトとしてデプロイ可能であることは、雲泥の差があるので本番環境に耐えうる技術的フィージビリティも考慮に入れる必要があります。そして、この際、（特にTEE特有の）セキュリティリスクをしっかりと把握・理解しておくことが重要です。

例えば、リスクを理解することで以下のようなアーキテクチャの設計をAnonifyで意識しています。

前述したようにメモリリソースの観点から物理マシンを意識して設計することになりますが、これは、鍵管理の観点からも同様です。Anonifyでは一部の処理でプロセッサに埋め込まれた鍵で暗号化処理をしています。この際、クラウド側のメンテナンスやオペレーションミスなどでノード（VM）と物理マシンの割り当てが解除されてしまうとノード側で取得する鍵が異なり暗号文が復号できなくなってしまうことが起こり得ます。このようなことに対処するために、物理マシンを考慮して冗長化し、万が一割り当てが解除されてしまっても一方のノードで復号可能となるようなアーキテクチャを設計する必要があります。

ちなみに、この幅広い技術分野にチームとして日々理解を深められるように、毎日勉強会を開催しています！（bizも参加・発表しています）

月曜：低レイヤー（OSなど）・TEE
火曜：暗号技術
水曜：サイバーセキュリティ
木曜：分野問わず最新の論文紹介など
金曜：ニュースレター

実装設計

TEEをベースにしたAnonifyの開発では、一般的なweb開発よりもエコシステムがかなり小さいので、活用できるライブラリが少なく多くのコードベースを自分たちで実装する必要があります。また、TEEの保護領域ではシステムコールを呼べないなどの技術的な制約も大きく、SDKなどを活用して特殊な実装をしたりする必要もあります。（詳しくは以下の記事を参考にしてください）

tech.layerx.co.jp

ここでは、現状の課題も含めてAnonify特有の実装設計方針をいくつか紹介します。

Composability

アーキテクチャレベルでサービスごとの疎結合性・カスタマイズ性を保つことも重要ですが、実装レベルでさまざまなコードベースを組み立てられるようなカスタマイズ性もさまざまなユースケースで用いられる前提のAnonifyでは重要です。例えば、あるユースケースではTEEでの認証・認可は必要ないが、他のユースケースではTEEでOauth2.0ベースの認可が必要になったりします。この場合、対応可能な認証・認可オプションを増やしていくことなどが改善ポイントとしてあげられます。

Security

TEEの保護領域で動くコードベースは最低限にすることで、信頼するソフトウェアのコードベースを減らします。例えば、ネットワークI/Oが絡むサーバーやクライアントとしての機能は保護領域の外で実装しています。一方、機密データの暗号化や復号は保護領域の中で実装しています。Anonifyにおいても、この保護領域内のコードベースを小さくするために、依存ライブラリを削減するなどの余地がある部分です。

Performance

TEE上での処理は通常の処理と比較しオーバーヘッドがかかります。これにはいくつかの要因があるのですが、その一つが保護領域内部とその外側で処理をコンテキストスイッチする際のオーバーヘッドです。Queueを使って非同期に処理するなどコンテキストスイッチコストを削減する論文や実装は多く提案されていますが、Anonifyではまだこの部分のパフォーマンス改善はできていない部分になります。