認証・ジョブ・インフラ管理・監視──手作業をなくすために進めた4つの自動化
環境払い出しの自動化にあたって、町田氏は「人手を介在させること自体がクラウド最大の恩恵である俊敏性と安全性を損なう」ことを前提にした。特にガバメントクラウドは、インターネット接続の制限や監視ルールの徹底など、厳格な統制要件を各テナンシーに漏れなく適用しなければならない。そこで手作業が残る限り、設定漏れや設定ミスといったセキュリティインシデントの火種は消えない。
したがって、各種APIを用いたシステム間連携やジョブ管理によってプロセスの完全自動化を図ることこそが、安全かつ迅速なクラウド基盤提供を実現するという仮説の基、町田氏はプロジェクトに着手した。
自動化の実現に向け、開発チームはスクラム開発の手法を採り入れた。ここで特徴的なのは、プロダクトオーナーである町田氏が「利用者が申請した日に環境を利用できる」といったユーザーストーリーの管理（What）に専念し、具体的な実装手段（How）には口を出さなかったことだ。一方で、ガバメントクラウド固有の厳格なセキュリティ要件を満たすため、デジタル庁内に「開発リード」という独自の役割を設け、民間事業者との認識のズレを埋める工夫を凝らした。
OKRを設定し、各プロダクトチームがスクラム開発を導入
システム面では、大きく4つの領域で自動化が推進された。第一に挙げられるのが「認証の自動化」である。クラウド環境における情報漏洩の多くは、APIキーなどの永続的な資格証明がソースコードに混入したり、不適切に管理されたりすることで発生する。この根本的なリスクを絶つため、町田氏らは永続キーの使用を一切禁じた。
代わりに採用したのが、Workload Identity Federationを用いた一時的なトークンによる認証フローだ。デジタル庁が独自開発したポータルサイト「GCAS」とOCIの間で信頼関係を結び、払い出しの処理が実行される瞬間だけ有効な一時トークンを発行してAPIを操作する仕組みを構築した。これにより、認証情報が漏洩して悪用される余地をアーキテクチャのレベルで排除している。
第二は「ジョブの自動化」だ。GCASへの申請情報をトリガーとして、一日一回ジョブ管理機能が自動的に起動し、プロビジョニングのプロセスを開始するよう構成した。
第三は「インフラ管理の自動化」であり、払い出し機能の実行環境としてKubernetes（OCIのマネージドサービスであるOKE）を採用した。コンテナ化されたアプリケーションをPodとして稼働させることで、万が一処理中に障害が発生しても、Kubernetesのセルフヒーリング機能によって自律的に復旧できる耐障害性の高いシステムを実現している。クレデンシャル情報はOCI Vaultで安全に一元管理され、システム全体にセキュアに受け渡される。
そして第四が「監視の自動化」だ。これらの一連の動作ステータスや、万が一のエラー状況は、本番環境のサーバーに直接ログインすることなく、すべてチャットツールのSlack上でリアルタイムに把握できるよう設計されている。GCAS側で管理される利用者情報と、OCI側で作成されるアイデンティティドメインとの間でSAML連携によるシングルサインオン環境も構築され、自動化の恩恵はインフラ構築だけでなく、利用者の日々のアクセス体験にも及んでいる。
手作業をなくすため、デジタル庁が実施した4つの自動化
OCIのアーキテクチャは親テナンシーと子テナンシーの独立性が高く、外部からガバナンス用のテンプレートを自動で流し込むプロセスにおいては、認証の壁から一回だけ手作業を残さざるを得なかった。しかし、それ以外の複雑なフローはすべてコード化され、機械的に処理される仕組みが完成した。
