$30 off During Our Annual Pro Sale. View Details »

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

itkq
April 22, 2024

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

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

itkq

April 22, 2024
Tweet

More Decks by itkq

Other Decks in Technology

Transcript

  1. © LayerX Inc. 2 • @itkq / いたこ • クックパッド

    → Ubie → LayerX (2023〜) ◦ 5+years SREをやってきました • 現在: バクラク事業部 Platform Engineering部 DevOpsチーム ◦ コーポレートエンジニアリングにも少し手を出したり • 好きなAWSのサービス: Amazon EventBridge whoami
  2. 4 © LayerX Inc. バクラク事業 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行

    * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を5秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を5秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
  3. © LayerX Inc. 6 • 「SRE」は組織図上は存在せず、代わりに「DevOps」チームがある ◦ クラウドインフラ全般、監視基盤、CI/CD、セキュリティなどを領域とする横断チーム ◦ 元々「SRE」だったが今はこの名前で、SREバックグラウンドのあるメンバーで構成される

    • サービスの運用 ◦ 権限移譲し、基本的にプロダクト開発チームが自身で運用 ▪ 問い合わせ対応、アラート対応、エラーログの監視 etc ◦ アーキテクチャの設計やインシデントハンドリング、パフォーマンス・キャパシティの問題など 開発チームとDevOpsで協働する機会も多い • コーポレートエンジニアリング室との関係 ◦ コーポレートエンジニアリング室は全社、DevOpsはバクラクが守備範囲 ◦ IdPとして使うMicrosoft Entra ID (旧Azure AD) など、厳密には線を引けていない部分 もある バクラクにおけるSRE バクラクについて
  4. © LayerX Inc. 7 • ほぼすべてAWS ◦ データ基盤や機械学習でGoogle CloudとMicrosoft Azureも利用

    • 極力マネージドサービスを使う ◦ 運用負荷やセキュリティリスク軽減が目的 • サービス用のComputeはLambdaとECS on Fargateですべて構成されている ◦ ただし、踏み台サーバとして唯一のEC2インスタンスがある バクラクのクラウドインフラ バクラクについて
  5. © 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コール 踏み台サーバ 負債: 踏み台サーバ
  6. © 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 踏み台サーバ図解
  7. © 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)
  8. © LayerX Inc. 12 • VPC内のリソースに手元から簡単にアクセスできること • IdP・MDM連携 • 運用負荷が低い

    • きめ細かい認可 • 通信のログ • 一時的な権限昇格機構 • これらを満たすソリューションを検討 ◦ → Twingate (全展開はongoing) 本当に必要だったもの 負債: 踏み台サーバ
  9. © LayerX Inc. 13 • https://www.twingate.com/ • “Zero Trust Networking”

    ◦ ネットワークおよびそのネットワークに接続しようとするユーザーが信頼されていないと見なされ る基本原則に基づいたネットワークアクセスモデル • Twingateを使ったVPC内のリソースへの到達(ざっくり) ◦ VPC内にデプロイした “Connector” とクライアントがP2P接続を確立し、これが透過的なプロ キシとして振る舞う • Alternatives ◦ Tailscale (Mesh VPN) ◦ 自作(?) Twingate 負債: 踏み台サーバ
  10. © 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
  11. © 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!
  12. © 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 ⑤一時的にアクセス可能
  13. © 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以降 負債: 踏み台サーバ
  14. © LayerX Inc. 21 PR: We are hiring! LayerXのプロダクトメンバーと美味しいお酒やご飯を囲み ながら、プロダクトやチーム、技術の話をゆる〜く行うイベン

    トを定期的に行っています。 直近の予定は以下のとおりです。 日程 テーマ 5/15(水) 19時ごろ〜 🍷ワイン Night LayerX Casual Night ※原則招待制です。気になるかたはDM等でコンタクトください。 LayerX Casual Night LayerX Open Door アカウント登録が一切不要なカジュアル面談を公開しています。 ・私と雑談してみたい ・質問したいことがある ・選考に進むか悩んでいる などなど、お気軽にお申し込みください。