© LayerX Inc. アクセス制御にまつわる改善 @itkq 2024-04-22 「SRE × 技術負債解消」のぶっちゃけ話LT会 

© LayerX Inc. 2 ● @itkq / いたこ ● クックパッド → Ubie → LayerX (2023〜) ○ 5+years SREをやってきました ● 現在: バクラク事業部 Platform Engineering部 DevOpsチーム ○ コーポレートエンジニアリングにも少し手を出したり ● 好きなAWSのサービス: Amazon EventBridge whoami 

© LayerX Inc. 3 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 LayerXの事業 バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン 

4 © LayerX Inc. バクラク事業 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を５秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を５秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能 

目次 Agenda ● バクラクについて ● 負債: 踏み台サーバ 

© LayerX Inc. 6 ● 「SRE」は組織図上は存在せず、代わりに「DevOps」チームがある ○ クラウドインフラ全般、監視基盤、CI/CD、セキュリティなどを領域とする横断チーム ○ 元々「SRE」だったが今はこの名前で、SREバックグラウンドのあるメンバーで構成される ● サービスの運用 ○ 権限移譲し、基本的にプロダクト開発チームが自身で運用 ■ 問い合わせ対応、アラート対応、エラーログの監視 etc ○ アーキテクチャの設計やインシデントハンドリング、パフォーマンス・キャパシティの問題など 開発チームとDevOpsで協働する機会も多い ● コーポレートエンジニアリング室との関係 ○ コーポレートエンジニアリング室は全社、DevOpsはバクラクが守備範囲 ○ IdPとして使うMicrosoft Entra ID (旧Azure AD) など、厳密には線を引けていない部分 もある バクラクにおけるSRE バクラクについて 

© LayerX Inc. 7 ● ほぼすべてAWS ○ データ基盤や機械学習でGoogle CloudとMicrosoft Azureも利用 ● 極力マネージドサービスを使う ○ 運用負荷やセキュリティリスク軽減が目的 ● サービス用のComputeはLambdaとECS on Fargateですべて構成されている ○ ただし、踏み台サーバとして唯一のEC2インスタンスがある バクラクのクラウドインフラ バクラクについて 

負債: 踏み台サーバ 

© LayerX Inc. 9 ● 構成 ○ 普通のAmazon Linux2 ○ Session ManagerでSSH (Port forwarding) する ■ AWS SSO + IAM Roleによるアクセス制御 ● 目的: VPC内のリソースへのアクセス ○ Aurora MySQL ■ アドホックなクエリ ○ OpenSearch Service ■ デバッグや調査目的でのAPIコール ○ Internal Endpoint (ALB, Service Connect) ■ デバッグや調査目的でのAPIコール 踏み台サーバ 負債: 踏み台サーバ 

© LayerX Inc. 10 負債: 踏み台サーバ AWS Cloud Virtual private cloud (VPC) Private subnet Session Manager Aurora MySQL Application Load Balancer EC2 (bastion) SSH (Port forwarding) bastion-authorized-keys Amazon OpenSearch Service ECS Service Connect Commit Public Key Pull (cron) Dev 踏み台サーバ図解 

© LayerX Inc. 11 ● Linuxユーザーが単一 ● 細かい認可制御がない ○ 踏み台に入れさえすれば、踏み台から到達可能なエンドポイントには誰でも到達可能 ○ データベースユーザーやAPIレベルの認証は別途存在 ● 手運用 ● セキュリティパッチが来たら適用するトイル ● SSH設定をちゃんとメンテできておらず、秘伝のタレ化 踏み台サーバの問題 負債: 踏み台サーバ # ~/.ssh/config イメージ Host bastion-dev HostName i-aaa LocalForward 30443 host1:443 LocalForward 31443 host2:443 (snip) LocalForward 33306 db1.ap-northeast-1.rds.amazonaws.com:3306 LocalForward 33307 db2.ap-northeast-1.rds.amazonaws.com:3306 (snip) 

© LayerX Inc. 12 ● VPC内のリソースに手元から簡単にアクセスできること ● IdP・MDM連携 ● 運用負荷が低い ● きめ細かい認可 ● 通信のログ ● 一時的な権限昇格機構 ● これらを満たすソリューションを検討 ○ → Twingate (全展開はongoing) 本当に必要だったもの 負債: 踏み台サーバ 

© LayerX Inc. 13 ● https://www.twingate.com/ ● “Zero Trust Networking” ○ ネットワークおよびそのネットワークに接続しようとするユーザーが信頼されていないと見なされ る基本原則に基づいたネットワークアクセスモデル ● Twingateを使ったVPC内のリソースへの到達(ざっくり) ○ VPC内にデプロイした “Connector” とクライアントがP2P接続を確立し、これが透過的なプロ キシとして振る舞う ● Alternatives ○ Tailscale (Mesh VPN) ○ 自作(?) Twingate 負債: 踏み台サーバ 

© LayerX Inc. 14 Twingate動作イメージ 負債: 踏み台サーバ Twingate Virtual private cloud (VPC) Private subnet Aurora MySQL Connector (ECS on Fargate) Controller Relay Client Microsoft Entra ID (IdP) P2P Connection + E2E TLS Tunnel Auth Auth Auth Proxy Signaling Signaling 

© LayerX Inc. 15 ● ConnectorとResourceを設定 ○ 注: 一部情報を改変 Aurora MySQLへの接続例 (1) 負債: 踏み台サーバ 

© LayerX Inc. 16 Aurora MySQLへの接続例 (2) 負債: 踏み台サーバ # before % dig db1.cluster-ro-aaa.ap-northeast-1.rds.amazonaws.com +short 10.x.y.z # プライベートIPアドレス % mysql -u reader -h dig db1.cluster-ro-aaa.ap-northeast-1.rds.amazonaws.com -p --connect-timeout 2 ERROR 2003 (HY000): Can't connect to MySQL server on 'db1.cluster-ro-aaa.ap-northeast-1 .rds.amazonaws.com:3306' (60) # after % dig db1.cluster-ro-aaa.ap-northeast-1.rds.amazonaws.com +short 100.X.Y.Z # Twingateが管理するCGNATアドレスレンジ % mysql -u reader -h dig db1.cluster-ro-aaa.ap-northeast-1.rds.amazonaws.com -p --connect-timeout 2 # ここでMicrosoft Entra IDの認証を求められる (snip) mysql>^DBye # Yay! 

© LayerX Inc. 17 デバイスポリシーの例 負債: 踏み台サーバ 

© LayerX Inc. 18 Twingate ● 本番環境へのデータベース書き込みなど緊急時にJust in timeで権限を付与したいケースがある ● Microsoft Entra Privileged Identity Management (PIM) の活用 ○ アクティブユーザー数の最適化も 一時的な権限昇格 負債: 踏み台サーバ Dev Microsoft Entra PIM ⑥時限式で削除 DevOps ②権限リクエスト、承認 Entra ID Group ③グループに追加 Entra ID Enterprise Application ④SCIM provisoning User Privileged Group ①権限昇格リクエスト Sync Resource: prd DB Writable Endpoint Allow ⑤一時的にアクセス可能 

© LayerX Inc. 19 ● ✅手元から直接Internal DNS名を指定してVPC内のリソースにアクセスできる ○ 必要なトラフィックだけがTwingateを経由する (Split tunneling) ● ✅Microsoft Entra ID as IdP、IntuneやJamf連携でデバイスポリシーを強制 ● ✅Connectorをデプロイするだけで、既存のネットワーク・インフラと干渉しない ● ✅SCIMでプロビジョニングしたグループ単位でResourceの認可を設定できる ● ✅監査ログ・通信ログをS3バケットに出力できる ● vs Tailscale ○ Internal DNSがある場合はIPアドレスを意識しなくて良くなる ○ 我々のユースケースではMeshは不要で、コストメリットあり ($10/user/mo vs $18/user/mo) Twingate以降 負債: 踏み台サーバ 

© LayerX Inc. 20 ● システムへのアクセス制御に関わる負債とその解消（解消中も含む）を紹介しました ○ 踏み台サーバ ● セキュリティファーストで、運用負荷を抑える手法を選択しています ○ Twingate ○ IdP/MDM ○ PIM (Privileged Identity Management) まとめ 

© LayerX Inc. 21 PR: We are hiring! LayerXのプロダクトメンバーと美味しいお酒やご飯を囲み ながら、プロダクトやチーム、技術の話をゆる〜く行うイベン トを定期的に行っています。 直近の予定は以下のとおりです。 日程 テーマ 5/15(水) 19時ごろ〜 🍷ワイン Night LayerX Casual Night ※原則招待制です。気になるかたはDM等でコンタクトください。 LayerX Casual Night LayerX Open Door アカウント登録が一切不要なカジュアル面談を公開しています。 ・私と雑談してみたい ・質問したいことがある ・選考に進むか悩んでいる などなど、お気軽にお申し込みください。