ZUNDA ID のリリースと内製IdPへの挑戦

はじめに

ZUNDA で提供しているあらゆるサービスに、ひとつのアカウントでログインでき、組織・部門・ユーザーレベルできめ細かく柔軟なセキュリティ設定に対応した『ZUNDA ID』をリリースします。

利用者の皆さまへ (ITサポート by ZUNDA および ZUNDA STORE をお使いのお客様)

2025年9月30日以降、これまでお使いいただいていたアカウントはそのまま引き継がれ、自動的にZUNDA ID へ統合されます。

お客様側での対応は不要です。 これまでどおりのログイン方法でそのままご利用ください。

ZUNDA ID で出来るようになったこと

ZUNDA ID の資格情報で ZUNDA の各サービスでログインできるようになりました

ITサポート by ZUNDA
ZUNDA STORE
ZUNDA DEX (提供予定)
ZUNDA CONNECT (提供予定)

これらのサービスへ、ZUNDA ID の資格情報を用いてワンクリックでログインできるようになりました。各サービスで別々の ID を持つ必要がなく、1つの ID でサインインできるため、利用者さまおよび管理者さまの運用負荷を抑えつつ、幅広いサービスをシームレスにご利用いただけます。

ポータル画面からサービスへ簡単にログイン出来るようになりました

ユーザーに割り当てられた権限をもとに、利用可能なサービスに自動的に絞り込まれた一覧が表示されます。ここから ZUNDA STORE などへ、これまで以上にスムーズにログインできます。

きめ細やかな権限制御が可能になりました

権限の集合であるロールと、ユーザーの集合であるグループを紐付けることで、効率的かつ精緻なアクセス制御が可能になりました。

さらに運用負荷を軽減するため、登録済みドメインのメールアドレスでのログイン時に自動でユーザー登録を行う「自動サインアップ」機能を搭載しています。自動で紐付けるグループも選択できるため、入社時に必要なグループへ自動登録するなど、初期設定の手間を大幅に削減できます。

将来利用可能になる機能

SCIM プロビジョニング

Entra ID など、SCIM プロビジョニングに対応した外部 IdP からのユーザーおよびグループの自動プロビジョニングに対応を予定しています。

OpenID Connect (OIDC) および SAML2 認証の対応

Okta など、組織で広く利用されている外部 IdP とのカスタム SSO に対応予定です。これにより組織で利用している追加のセキュリティ施策 (デバイス証明書、IPアドレス制限、ログ監査など) を ZUNDA ID に適用できるようになります。

なお、現時点では以下の認証方法に対応しています。

Microsoftログイン
Googleログイン
メール認証

Passkey (FIDO2/WebAuthn) 認証の対応

画像のようなハードウェア認証装置を用いたセキュアな認証にも、今後対応を予定しています。外部 IdP (例: Entra ID) をご利用中の方には影響が小さい場合もありますが、メール認証のみをご利用の環境では、より認証を強固にできます。

ZUNDA ID 開発裏話

ここからは開発の裏話になりますので、ご興味があればぜひ読んでください。

開発のはじまり

ZUNDA では現在、ZUNDA DEX および ZUNDA CONNECT ROUTER の開発を進めており、社外に提供するサービスが年内に1つ、2つと増えていく見込みです。そのたびに「プロジェクトごとに ID 基盤をどうするか？」という議論が発生するため、サービスを横断した共通 ID 基盤を社内で構築し、全体で同じセキュリティレベルと利便性を確保しよう、という話になったのがこのプロジェクトの出発点でした。

当初は開発責任者である私・大石ともうひとりのメンバーで始まり、付き合いが長く k8s (Kubernates) に詳しいオタク (余談ですが大学時代からの10年来の友人です) も誘い、さらに別の大学の友人も加わって、リードエンジニア1人、インフラ1人、フロントエンド1人、バックエンド・フロントエンド1人という体制に。3〜4ヶ月の短期で、開発・QA・UAT を回してリリースに至りました。

ちなみに弊社の採用活動は、なぜか「びっくりドンキー」か「山岡家」。少し良いお店で面談すると不思議とお断りされがちで、気づけばこの二択が定番に。

Google Kubernetes Engine (GKE) Autopilot と ASP.NET Core MVC をフルに活用したセキュアで柔軟なインフラ・バックエンド環境の実現

ZUNDA ID においては以下のような構成を取っています。

バックエンド
- .NET 8 (LTS)
- C#
- ASP.NET Core MVC
フロントエンド
- Next.js
- React.js
- Tailwind CSS
- shadcn/ui
- Storybook
- TypeScript
インフラ
- Google Kubernetes Engine (GKE) Autopilot
- cert-manager を使った Cloudflare の証明書管理
- Envoy Gateway を使った L4LB - CDN 間の mTLS を使った認証と暗号化
- Spot Pod を活用した柔軟かつ安価なインフラ
- Terraform を使った完全な IaC でのインフラ管理

バックエンドには、日本では採用事例が多くない一方で海外では広く採用されている .NET を採用しました。高パフォーマンスで堅牢な静的型付け言語であること、周辺ライブラリが安定していることが決め手です。ランタイム標準の機能が豊富で、他言語や他ランタイムだと外部ライブラリに頼らざるを得ない部分を減らせるため、依存の削減はアップデート工数やセキュリティリスクの低減にも直結します。

インフラには k8s を全面的に採用し、証明書管理からアプリのデプロイまでをクラスタ内で完結しています。Terraform で k8sを含むすべてのインフラを構成し、Helm と Helmfile、ArgoCD、Kustomize を組み合わせることで、再現性があり移植可能なインフラを実現。内部向けの開発環境と本番環境で、スペック以外の差がほぼない環境を構築しやすくなり、管理工数を大幅に削減できました。

フロントエンドでは shadcn/ui と Tailwind CSS を UI に採用し、Next.js で SSR する構成です。ASP.NET Core MVC 側の API 定義を OpenAPI としてエクスポートし、そこから型安全なTypeScript の API クライアントを生成。型というガードレールを活かして効率よく開発を進める工夫をしました。

また、これらすべての構成要素は k8s の単一クラスタ内にデプロイされ、内部通信は Istio の mTLS で認証・暗号化されています。少人数チームでもセキュリティ要件を満たしつつ高い生産性を維持できるよう、安定した技術を選びながらも、運用を任せられる“少し攻めた”技術を採用しています。

OpenID Connectを使ったシステム間の連携

ZUNDA ID では OpenID Connect (OIDC) を使って認証と認可をしています。つまり、ZUNDA ID は付随するサービス (RP) にとっての IdP の位置づけになります。

(厳密に言うと、ZUNDA ID へのログインにシングルサインオンを利用できるため、ZUNDA ID は IdP であり RP でもあります)

弊社ではこれまで Auth0 や Firebase Authentication といった IDaaS を使っていましたが、既存の IDaaS では実現できないパフォーマンス、コスト、仕様などの要件を満たすため、独自の認証基盤を開発することにしました。

しかし、独自仕様に寄せすぎるとかえってセキュリティのレベルが低下したり、RP 側の実装コストが増えてしまうリスクがあります。そこで、標準仕様である OIDC を採用し、テスト済みで安定したライブラリ群を活用することで、セキュリティを維持しつつ工期を短縮しました。シングルサインアウト実現のために一部拡張は行っていますが、基本的には成熟したライブラリを用いて実装しており (お世話になっているライブラリには何度かコントリビュートしています)、品質を担保しながら開発を進めています。

最後に

（上は筆者が大好きなyosugalaの未白ちあに会いに行くために大阪に行ったときの写真）

Entra ID、Okta、Google Cloud IdentityなどのクラウドID 製品をお客様に提供している我々として、IdP 製品の実装と統合を深く理解するためには、IdP を内製化することはもはや必然でした。

そして、ちょうどこの写真を撮ったときが、コードベースの initial commit が積まれ始めた時期でした。あれから数ヶ月……ようやくリリースまでこぎ着けられたと思うと、感慨深いものがあります。これからの ZUNDA ID に、ぜひご期待ください。