アクセス制御にまつわる改善 / Improving access control

「SRE × 技術負債解消」のぶっちゃけ話LT会 https://coconala.connpass.com/event/314300/ で発表したスライドです

Transcript

1. © LayerX Inc. アクセス制御にまつわる改善 @itkq 2024-04-22 「SRE × 技術負債解消」のぶっちゃけ話LT会
2. © LayerX Inc. 2 • @itkq / いたこ • クックパッド → Ubie → LayerX (2023〜) ◦ 5+years SREをやってきました • 現在: バクラク事業部 Platform Engineering部 DevOpsチーム ◦ コーポレートエンジニアリングにも少し手を出したり • 好きなAWSのサービス: Amazon EventBridge whoami
3. © LayerX Inc. 3 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 LayerXの事業 バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン
4. 4 © LayerX Inc. バクラク事業 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を５秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を５秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
5. 目次 Agenda • バクラクについて • 負債: 踏み台サーバ
6. © LayerX Inc. 6 • 「SRE」は組織図上は存在せず、代わりに「DevOps」チームがある ◦ クラウドインフラ全般、監視基盤、CI/CD、セキュリティなどを領域とする横断チーム ◦ 元々「SRE」だったが今はこの名前で、SREバックグラウンドのあるメンバーで構成される • サービスの運用 ◦ 権限移譲し、基本的にプロダクト開発チームが自身で運用 ▪ 問い合わせ対応、アラート対応、エラーログの監視 etc ◦ アーキテクチャの設計やインシデントハンドリング、パフォーマンス・キャパシティの問題など 開発チームとDevOpsで協働する機会も多い • コーポレートエンジニアリング室との関係 ◦ コーポレートエンジニアリング室は全社、DevOpsはバクラクが守備範囲 ◦ IdPとして使うMicrosoft Entra ID (旧Azure AD) など、厳密には線を引けていない部分 もある バクラクにおけるSRE バクラクについて
7. © LayerX Inc. 7 • ほぼすべてAWS ◦ データ基盤や機械学習でGoogle CloudとMicrosoft Azureも利用 • 極力マネージドサービスを使う ◦ 運用負荷やセキュリティリスク軽減が目的 • サービス用のComputeはLambdaとECS on Fargateですべて構成されている ◦ ただし、踏み台サーバとして唯一のEC2インスタンスがある バクラクのクラウドインフラ バクラクについて
8. 負債: 踏み台サーバ
9. © 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コール 踏み台サーバ 負債: 踏み台サーバ
10. © 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 踏み台サーバ図解
11. © 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)
12. © LayerX Inc. 12 • VPC内のリソースに手元から簡単にアクセスできること • IdP・MDM連携 • 運用負荷が低い • きめ細かい認可 • 通信のログ • 一時的な権限昇格機構 • これらを満たすソリューションを検討 ◦ → Twingate (全展開はongoing) 本当に必要だったもの 負債: 踏み台サーバ
13. © LayerX Inc. 13 • https://www.twingate.com/ • “Zero Trust Networking” ◦ ネットワークおよびそのネットワークに接続しようとするユーザーが信頼されていないと見なされ る基本原則に基づいたネットワークアクセスモデル • Twingateを使ったVPC内のリソースへの到達(ざっくり) ◦ VPC内にデプロイした “Connector” とクライアントがP2P接続を確立し、これが透過的なプロ キシとして振る舞う • Alternatives ◦ Tailscale (Mesh VPN) ◦ 自作(?) Twingate 負債: 踏み台サーバ
14. © 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
15. © LayerX Inc. 15 • ConnectorとResourceを設定 ◦ 注: 一部情報を改変 Aurora MySQLへの接続例 (1) 負債: 踏み台サーバ
16. © 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!
17. © LayerX Inc. 17 デバイスポリシーの例 負債: 踏み台サーバ
18. © 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 ⑤一時的にアクセス可能
19. © 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以降 負債: 踏み台サーバ
20. © LayerX Inc. 20 • システムへのアクセス制御に関わる負債とその解消（解消中も含む）を紹介しました ◦ 踏み台サーバ • セキュリティファーストで、運用負荷を抑える手法を選択しています ◦ Twingate ◦ IdP/MDM ◦ PIM (Privileged Identity Management) まとめ
21. © LayerX Inc. 21 PR: We are hiring! LayerXのプロダクトメンバーと美味しいお酒やご飯を囲み ながら、プロダクトやチーム、技術の話をゆる〜く行うイベン トを定期的に行っています。 直近の予定は以下のとおりです。 日程 テーマ 5/15(水) 19時ごろ〜 🍷ワイン Night LayerX Casual Night ※原則招待制です。気になるかたはDM等でコンタクトください。 LayerX Casual Night LayerX Open Door アカウント登録が一切不要なカジュアル面談を公開しています。 ・私と雑談してみたい ・質問したいことがある ・選考に進むか悩んでいる などなど、お気軽にお申し込みください。