CNDT2021、メルカリがマイクロサービスのセキュリティを強固にするための施策を解説

CNDT2021から、メルカリのエンジニアリング部門のマネージャーである中島大一氏によるマイクロサービスのセキュリティを強化するための施策に関するセッションを紹介する。

タイトルは「How We Harden Platform Security」

メルカリには「メルカリ」と「メルペイ」という2つの大きなサービスが存在し、それぞれがマイクロサービスとしてGCPの上のKubernetesに実装されている。合計200以上のマイクロサービスが、4000個以上のPodによって配備されているという。

メルカリとメルペイのサービスはマイクロサービスとして実装

メルカリは2020年のCNDTでもセッションを行っており、その際はメルペイ側のSREである高木氏が講演を行い、デベロッパー自身が運用まで行うという特徴的な体制について解説を行っている。今回の中島氏の講演でも、運用に専任しているエンジニアはおらず、プラットフォームの自動化などを行うエンジニアが存在するという内容を解説した。

参考：CNDT2020シリーズ：メルペイのマイクロサービスの現状をSREが解説

メルカリ全体のセキュリティを強化するための施策について、3つのポイントに絞って解説を行ったのが今回のセッションである。基本はそれぞれのレイヤーにおいてのセキュリティを確保するだけではなく、多層防衛として複数のレイヤーに跨った深い防御を行うことが重要だと解説し、今回はその中から3つを紹介している。

3つのポイントでセキュリティを強化

開発環境におけるセキュリティ

メルカリのプラットフォームは、マルチテナントを前提としてKubernetesのネームスペースによって分離されている。その際に特権の付与については、最低限必要なものだけを与える「Least Privilege」を基本としているという。

最低限の特権だけをテナントに渡す方針

これは実行環境であるKubernetesとアプリケーションをビルドするCI/CD開発環境においても適用されているおり、デベロッパーからビルドシステムへのアクセス、そしてビルドシステムからGCP上のKubernetesへのアクセスという2点において、最低限の特権を管理する方法が取られていると説明した。

実行環境だけではなくCI/CDにもLeast Privilegeを適用

Kubernetesにおいては、RBAC（Role Based Access Control）とネームスペースを使って特権の制御を実装していることを解説。リポジトリーについてはチームごとのにディレクトリー構造に分かれており、そのディレクトリーに対するアクセスを制限する方法を取っていると説明した。

サービスAのチームはサービスAのネームスペースしかアクセスできない

リポジトリー内の特権の解説に続いて、Infrastructure as Code（以下、IaC）におけるセキュリティについて説明を行った。

単一のリポジトリーを使ってビルドシステムを構築

この図ではIaCとして管理されているリソースの設定情報などについて、GitHubに対するPull Requestを使って修正や追加を行うことで、サービスチームが直接クラスターなどの設定情報にアクセスしない仕組みになっていることを説明した。

CODEOWNERだけがサービスのリソースにアクセス可能

ここでは各サービスチームでは、CODEOWNERというロールを持つユーザーだけがネームスペース配下に構築されるリソースにアクセスできることを解説している。

ビルドシステムが持つサービスアカウントが大きな特権を持ってしまうことでリスクが高まることも認識しており、そのために長い時間を掛けてシステムを見直したことを説明。ここではビルドシステムの管理者アカウントが直接サービスの管理者特権を取得する方法ではなく、サービスにおける管理者アカウントに成り代わる形でサービス内のリソースにアクセスできるように設計していることを解説した。

サービスの管理者に成り代わる（Impersonate）ことでアクセスを可能に

このImpersonate機能によって、ビルドシステムがアクセスできる特権を必要最低限の範囲に制限できることを説明した。

本番環境におけるセキュリティ

次に本番環境におけるセキュリティについての解説に移った。

本番環境は直接操作できなくするのがポリシー

ここでは本番環境をエンジニアが直接操作するのではなく、IaCに関わるコードをリポジトリーの中で編集することでビルドシステムが環境を操作する方法を採用していると説明した。この方法は、Googleの社内のポリシーであるゼロタッチプロダクションを参考にしていることを紹介。また臨時にロールを与える機能を使うことで、通常の運用の90％の操作は実行できると解説したが、残りの10％、つまり緊急時にPodをリスタートさせたり、入れ替えたりという操作が必要になると説明した。

臨時にサービスのインフラへのアクセスを可能にする機能で運用をカバー

ここではそのような緊急の操作についてリスクを軽減するためのツールとして、Lyftが開発して公開しているClutchというツールを使ってリソースの可視化などを行っていると解説した。

Clutchを使って操作を可視化

Clutchについては以下の公式サイトを参照されたい。

Clutch：https://clutch.sh/

ソフトウェアのサプライチェーンにおけるセキュリティ

最後に、ソフトウェアのサプライチェーンにおけるセキュリティについて解説を行った。

ソースコードからクラスターへの配備までに存在する様々なリスク

ここではソースコードからビルド、クラスターへの配備までのプロセスにおいて、多くの危険な箇所が存在することを説明し、どこか一ヶ所が破られただけでシステム全体が危険に晒されてしまうことを強調した。

ユーザーアカウントの管理だけではなく成果物の検証が必要

ここでもゼロタッチプロダクションと同様に、オライリーの書籍であるBuilding Secure and Reliable Systemsからの引用を行い、ユーザーではなく成果物に対する検証が必要であることを解説した。

Kritisを使いビルドされたものの同一性を確認するプロセスを追加

ここではソースコードをビルドした成果物が、実際にクラスターに配備されるものと同一かどうかを検証するためのツールとしてKritisが紹介されている。KritisはGrafeasの一部として公開されているオープンソースソフトウェアだ。詳しくは、以下のInfoQの記事と公式リポジトリーが参考になるだろう。

参考：Software Supply Chain Management with Grafeas and Kritis

Kritis：https://github.com/grafeas/kritis/blob/master/docs/binary-authorization.md

あとからセキュリティを強化するのは難しい

ここではセキュリティの強化を後付けで行うことは非常に難しく、多くの時間と労力が必要になるというメルカリ自身の経験からのコメントがあった。許可しないリストをベースにセキュリティを実装するのではなく、許可することを選んでそれだけを使うような発想でシステムを構築するべきだと説明した。

インフラを直接エンジニアに触らせないためには抽象化が必要

またインフラストラクチャーが常に一定ということは有り得ないので、デベロッパーが使うレイヤーは抽象化して配下のインフラストラクチャーを直接操作するような手法は避けるべきだと解説して、セッションを終えた。実際にKubernetes上でマルチテナント、単一リポジトリーでIaCを実践しているメルカリの手法がそのまま多くの企業で応用できるかは分からない。しかし、マルチテナントなKubernetesに実装、許可リストから始めること、多層のレイヤーで防御を実装することなどヒントになる内容が多いセッションとなった。