Head of DevOps, SRE & Security (DevSecOps)
6か国・145名の組織を率いたGroup CTOで、今も自ら手を動かしています。中央銀行の決済基盤、3つのクラウドで動くAIエージェント基盤、ベアメタル上の10基のA100、そして監査に合格した2つの認証。
- 99.999%カンボジア国立銀行の決済システムBakongにおいて
- 指摘0件ISO 27001サーベイランス審査での結果。SOC 2 Type IIは2回合格
- 145名6か国に在籍。報告先は最高経営責任者
経歴
担当してきた領域
8つの領域、共通の証拠基準
リーダーシップ
145名 · 6か国Group CTO · Head of DevOps, SRE & Security
リーダーシップ
145名 · 6か国- 組織全体が私の管掌で、拠点は日本、ロシア、スイス、モンテネグロ、タイ、ドバイにありました。私自身は最高経営責任者に報告していました。
- まず技術組織を構築しました。ピーク時の直属メンバーは37名で、内訳はDevOps 12名、セキュリティ6名、QA 19名です。
- Everworkerではゼロからのスタートで、ツールもプロセスも人員もありませんでした。4名のセキュリティチームを立ち上げました。
決済とCBDC
99.999%Bakong · CBDCパイロット
決済とCBDC
99.999%- カンボジア国立銀行の決済システムBakongの信頼性とセキュリティを担当しました。システムはJavaで書かれ、Hyperledger Iroha上で稼働します。
- 2024年の決済額は1500億ドル超で、カンボジアのGDPの約330%に相当し、2025年の決済件数は13億件です（NBC公表値）。
- グループ全体でCBDCパイロットを実施。Central Banking誌の「CBDC Partner of the Year」（2020年）に貢献しました。
プラットフォームとAI
300超のアプリ · IaC 99%AWS · Azure · GCP · ベアメタル
プラットフォームとAI
300超のアプリ · IaC 99%- 3つのクラウドで動くAIエージェント基盤を、SaaSとして、またお客様自身のアカウントでのセルフホスト版として提供しています。
- 有償パートナーが必要だと言われたものの、単独で3つのクラウド向けHelmチャート付きのAWS Marketplace出品を実現しました。 AWS Marketplace
- ドバイのMoro Hub（Tier III）にNVIDIA A100を10基、ベアメタルで導入しました。きっかけは、放置されたGPUインスタンス1つが2日で数千ドルを消費したことです。
- 300超のアプリケーション、700超のリポジトリ、6つのGitHub組織。ビルド時間を40%短縮し、コストを30%以上削減しました。
信頼性
MTTR −60%SREプラクティスをゼロから確立
信頼性
MTTR −60%- 4地域の20超のストリームアラインドチームに組み込まれたSREとして、SLI、SLO、エラーバジェット、インシデントコマンド、ブレームレスレビューを担いました。
- SLAを99%から99.99%へ引き上げました。ミッションクリティカルな5システムのバックアップとDRを自動化し、リストアは実際に実行しました。
- 無理なく続けられるオンコール体制：日次のローテーション、各シフトにバックアップ担当、すべてのアラートにランブックとメトリクス。
セキュリティとアシュアランス
サーベイランス審査での指摘0件ISO 27001 · SOC 2 Type II · NIST CSF
セキュリティとアシュアランス
サーベイランス審査での指摘0件- ISO/IEC 27001:2022：初回審査で指摘された5件の軽微な不適合を是正し、その後のサーベイランス審査（初年度）を指摘事項ゼロで通過しました。 Trust Center
- SOC 2 Type IIに2年連続で合格し、対象範囲をプライバシーと可用性に拡大しました。お客様の要請を受け、NIST CSFプログラムを推進しました。
- 100名超の開発者向けにセキュアSDLCを展開：STRIDEとVASTの脅威モデル、CVSSとEPSSによるスコアリング、セキュリティチャンピオン。脆弱性の露出期間を70%短縮しました。
- 独立したペネトレーションテスト：指摘12件（高1件、中6件、低5件）をトリアージし、主要なものはDASTの回帰チェックに変えて、継続的にテストされる状態にしています。
プロダクト
2プロダクト · 12名×2チームエンドツーエンドで担当
プロダクト
2プロダクト · 12名×2チーム- カリブ海の島々向けの決済システム。専任の12名のチームを持ちました。
- 大規模エコシステム向けのロイヤルティポイントシステム。こちらも専任の12名のチームです。
Web3
決済と同じゲートPolkadot · Klaytn · SORA
Web3
決済と同じゲート- Web3 Foundationのグラント、Polkadotエコシステムでの開発、KlaytnおよびSORAエコシステムを、決済システムと同じパイプラインとセキュリティゲートで扱いました。
- Next-Generation Payments 2023およびバンコクのフィンテックカンファレンスに登壇しました。
インシデントレビュー
インシデント対応、監査、クライアントのプラットフォームでの作業から。どの事例も、パッチではなく統制の整備で締めくくっています。
ソースコードの持ち出しと恐喝の試み
分析したイベント87,000件
- 検知
リポジトリで異常なアクティビティを検知。
- 調査
87,000件のイベントを含む監査ログのエクスポートを対象にフォレンジックを実施。認証情報の影響範囲は、想定ではなく再検証で確認しました。
- 対策
封じ込めと認証情報のリセットを行い、その後、組織全体のアクセス権をPulumiのIaCとして再構築し、手動付与が再発しないようにしました。
監視が捉えられなかった認証情報のローテーション
データ損失0・当日中に修正
- 検知
クライアントのプラットフォームで、マネージドDBがスケジュールどおりにマスターパスワードをローテーションし、夜間にアプリがDB接続を失いました。アラートは発報していません。
- 調査
アプリはパスワードをデプロイ時に1回しか読み込んでいませんでした。アラート設定を見直したところ、どのルールもそれぞれ別の形で検知できない状態でした。プロセスは稼働したままで、エラー閾値は完全停止でもこのトラフィックでは届かない水準にあり、プールのアラートは原因を遅いクエリとして示していました。
- 対策
同日中に、アプリを最小権限のロールとチームが管理するパスワードに切り替え、その認証情報でログインできない場合はデプロイが失敗するようにしました。空のプール、ヘルスエンドポイント、接続数の下限、バックアップ欠落に対する新しいアラートも追加しました。データは失われていません。
4件に1件でWebhookが失敗
上流で修正済み、全ユーザーに反映
- 検知
クライアントのプラットフォームで、固定していたリリースの下で上流のイメージが変わった後、POSTリクエストの約4分の1でWebhookの500、署名の不一致、CSRFエラーが発生しました。
- 調査
chunkedのリクエストボディが空のままアプリに届いていました。アプリはContent-Lengthでボディを読みますが、chunkedリクエストにはそれがありません。500はどこにも記録されていませんでした。フレームワークの既定のロギングが、debug無効の状態でそれを握りつぶしていたためです。
- 対策
オープンソースのデプロイツールでリクエストのバッファリングを既定にし、アプリ側でもWSGI層でchunkedを解除し、Webhookは5xxを返さないようにしました。エラーは構造化ログに出力されます。
Connection refused、一度に14秒間
7,254回のプローブで失敗0
- 検知
クライアントのプラットフォームのエンドユーザーから、ポート443で接続拒否が報告されました。クラウドのオートスケーラーはその日、エッジプロキシを37回退避させており、それまでは1日0から8回でした。
- 調査
プロキシのドレインは10秒でしたが、ロードバランサーがノードを外すのに約24秒かかっていました。0.5秒間隔のプローブで再現し、新規接続の約半数が失敗する14秒間の窓を確認しました。
- 対策
ドレイン時間をヘルスチェックより長くし、プロキシをホスト間に厳密に分散させ、両方の設定をオープンソースのツールに追加しました。ロールアウトをまたいだ7,254回のプローブで失敗は0です。
省略できる手順があったリリースプロセス
デプロイはオールオアナッシングに
- 検知
クライアントのプラットフォームで、稼働率が緑のまま、本番がバックグラウンドタスクの処理系なしで20から30分稼働していました。ワーカーがデプロイされておらず、アラートの対象がなかったためです。
- 調査
リリースは別々の手動手順2つ、先にweb、次にworkerに依存しており、両方が実行されたかを確認する仕組みはありませんでした。マージ前チェックとアドミッション制御は除外しました。gitは正しく、ワーカーはそもそも投入されていなかったためです。
- 対策
分割されたサービスは、順序付きの1つのworkflowとしてデプロイされ、両方が成功しない限り赤になります。単独のワーカーデプロイは廃止しました。パリティアラートは最後の砦として残しています。
誰にも信用されなかったアラート
誤検知89% → 0
- 検知
14日間でCloudTrailアラームが232回発報し、約89%が誤検知でした。
- 対策
CIS基準に加えて8つの検知ルールを追加し、ルールごとに除外条件を設定しました。1日の発報は1桁、最初の観測期間の誤検知はゼロ、すべてのアラートにランブックを用意しています。
見張りをやめた監視役
停止した実行は自動で解消
- 検知
クライアントのdead-man's switchが気づかれないまま止まっており、4.5日間、定期実行がすべてキャンセルで終わっていました。
- 調査
CIプラットフォームがキューに残した1件の実行が、concurrency groupを占有し続けていました。ジョブの開始前にはタイムアウトが効かないため、後続の実行はすべて待機してからキャンセルされました。1日以内に再発しました。
- 対策
短い定期実行のworkflowは、実行中のものをキャンセルするようにしました。止まった実行は次の実行に置き換えられ、ブロックされなくなります。
CPU 4%で請求が52%増
固定11ノード → 需要に応じた5-9ノード
- 検知
クライアントのプラットフォームでのコスト見直し。予測額が1か月で52%上昇し、18台のノードがCPU約4%で稼働していました。
- 調査
デプロイツールの既定のdisruption budgetでは、単一レプリカのサービスに許可されるエビクションが0で、オートスケーラーはどのノードもドレインできませんでした。新しいwhite-labelが増えるたびに、ノードが1台ずつ固定されていきました。
- 対策
エビクションを1件許可するbudgetを13のリポジトリに展開しました。本番は固定の11ノードから需要に応じた5-9ノードに、stagingは7から3になりました。上流の既定値の変更は見送りました。決済系の本番には、蓄積した変更が多すぎたためです。
社内に存在しないツールを前提としていたISMS
検証したポリシー29本
- 検知
引き継いだAI起草のポリシー29本が、存在しないMDM、EDR、ディレクトリサービスを参照していました。
- 対策
承認の前に、記載された全ツールと役割の実在確認を必須にしました。AIは下書きを作り、判断は証拠が行います。