権限管理基盤の開発とQAの今 / Authority Management Infrastructure Development and QA Now

Transcript

1. 権限管理基盤の開発とQAの今 sentokun/harashin 2024年6⽉1⽇
2. 2022年8月中途入社。10年組込 → Webエンジニア → freee でエ ンジニアリングマネージャーに。 ニックネームは sentokunくんづ けのままで呼ぶか迷われがち
 2 辻裕士/sentokun
 権限管理基盤チーム エンジニアリングマネージャー 2021年にfreeeに入社。これまで にモバイルQAE/会計QAE/SWE in Qualityを経験。現在は基盤 QAEとして奮闘中。自称、社内 ジョブホッパー。
 原田晋/harashin
 権限管理基盤チーム QAマネージャー
3. 　 01 freee の権限管理基盤とは 02 権限管理基盤のマジ価値 03 マジ価値が届くまで 04 権限管理基盤のこれから ⽬次
4. 　 01 freee の権限管理基盤とは 02 権限管理基盤のマジ価値 03 マジ価値が届くまで 04 権限管理基盤のこれから ⽬次
5. 統合型経営プラットフォームを⽬指す freee
6. 統合型経営プラットフォームを⽬指す freee 権限体験の統⼀が必要
7. 権限体験の統⼀とは freee 会計 freee ⼈事労務 • 権限に関わるユーザー体験をプロダクトで同じ状態にすること ◦ 今はプロダクトごとに異なる
8. 権限体験が統⼀されていないとなにが困るの？ ユーザーにとって • freee のプロダクトを業務に取り⼊れるたび、使い⽅を覚える必要あり freee の開発者にとって • 権限制御を⾃⾝で適切に実装‧運⽤‧拡張しつづけなければならない プロダクトの企画者にとって • プロダクトの権限制御を時間とコストをかけて提供する必要がある
9. 権限体験が統⼀されていないとなにが困るの？ ユーザーにとって • freee のプロダクトを業務に取り⼊れるたび、使い⽅を覚える必要あり freee の開発者にとって • 権限制御を⾃⾝で適切に実装‧運⽤‧拡張しつづけなければならない プロダクトの企画者にとって • プロダクトの権限制御を時間とコストをかけて提供する必要がある 権限管理基盤で解決するぞ！
10. 権限管理基盤とは • 複雑な権限制御を誰にとっても、簡単に、わかりやすく提供する基盤 ◦ プロダクトは基盤を導⼊するだけで、権限制御に関わる機能を実現できる！ ◦ freee のための Platform as a Service となるのが理想 プロダクト 1 プロダクト 2 …
 freee ユーザー
 権限管理基盤

11. 権限管理基盤が提供する価値 ユーザーにとって • どのプロダクトでも業務に沿って安全かつ簡単に権限を運⽤できる freee の開発者にとって • 権限制御を基盤に任せ、⼿軽で安全に導⼊‧運⽤‧拡張できる プロダクトの企画者にとって • プロダクトの権限制御を素早くリーズナブルに提供できる
12. 　 01 freee の権限管理基盤とは 02 権限管理基盤のマジ価値 03 マジ価値が届くまで 04 権限管理基盤のこれから ⽬次
13. 　 権限制御ってなに？
14. 権限制御ってなに？ • A. アクセス制御ポリシーに従い、ユーザーの属性に合わせて適切な アクセス制御を⾏うこと
15. 権限制御ってなに？ • A. アクセス制御ポリシーに従い、ユーザーの属性に合わせて適切な アクセス制御を⾏うこと
16. 権限制御ってなに？ • A. アクセス制御ポリシーに従い、ユーザーの属性に合わせて適切な アクセス制御を⾏うこと ユーザー属性 ってなに？
17. ユーザー属性 • freee ユーザーは、様々な属性を持っている ▪ 管理者、メンバーなどの役割 (ロール) ▪ ユーザーの契約プラン (ライセンス) ▪ etc
18. 権限制御ってなに？ • A. アクセス制御ポリシーに従い、ユーザーの属性に合わせて適切な アクセス制御を⾏うこと 適切なアクセス制御 ってなに？
19. 対象の機能を使っていい⼈だけが、画⾯やエンドポイントなどにアク セスできるよう制御すること OK
 NG
 ×
 管理者 メンバー 適切なアクセス制御
20. 権限制御ってなに？ • A. アクセス制御ポリシーに従い、ユーザーの属性に合わせて適切な アクセス制御を⾏うこと アクセス制御ポリシー ってなに？
21. アクセス制御ポリシー = アクセスしていい条件の集まり • 設定ファイルでユーザーの属性となにが許可されているかを記載 ◦ 許可機能とユーザー属性を紐付け ◦ 許可エンドポイントと機能を紐付け => ユーザー属性と紐付け …. … … アクセス制御ポリシー 管理者なら
 許可
 有料プランなら許 可

22. 権限制御ってなに？ • A. アクセス制御ポリシーに従い、ユーザーの属性に合わせて適切な アクセス制御を⾏うこと OK
 NG
 ×
 管理者 メンバー …. … … アクセス制御ポリシー 管理者なら
 許可

23. 権限管理基盤を利⽤したアクセス制御の実現 • 権限管理基盤は、設定ファイルに従いアクセス制御の判定を⾏う • プロダクトは、判定結果を元に適切なアクセス制御を実現できる
24. 多様‧多層なアクセス制御の提供が価値を広げる • 権限管理基盤が提供する多様‧多層なアクセス制御とその品質 = プロダクトが提供できる権限制御 多層なアクセス制御 多様なアクセス制御 ロール ライセンス …
25. 　 どんなアクセス制御があるの？
26. この話 多様なアクセス制御 ロール ライセンス
27. RBAC / ロールベースアクセス制御 • ユーザーの業務に合わせたロールによる制御 ◦ 例: 勤怠申請はみんなできるが承認は管理者しかできない • ⼀般⽤語、AWS の IAM ロールなどと同じ概念 OK
 NG
 ×
 管理者 メンバー
28. RBAC の流れをアクセス制御ポリシーで説明 • 権限管理基盤はロールに対するアクセス制御ポリシーを持つ ◦ 例: 管理者 → 承認機能を利⽤できる • 管理者は、ユーザーを招待する際にロールを割り当てる • ユーザーに割り当てられたロールを元に、アクセス制御ポリシーに 基づいてアクセス制御を⾏う ◦ 例: 管理者 → 承認ボタンを表⽰
29. LBAC / ライセンスベースアクセス制御 • ユーザーの契約プランに紐づいたライセンスによる制御 ◦ プレミアムなら仕訳承認フローが使えるといったアクセス制御 • freee 独⾃の造語、freee プロダクトに合わせたアクセス制御 OK
 NG
 ×
 プレミアムプラン スタンダードプラン
30. LBAC の流れをアクセス制御ポリシーで説明 • 権限管理基盤はライセンスに対するアクセス制御ポリシーを持つ ◦ 例: プレミアムプランに紐づいたライセンス → 仕訳承認機能を利⽤できる • ユーザーは、freee のプランを契約する • freee は、ユーザーに契約プランに応じたライセンスを割り当てる • ユーザーに割り当てられたライセンスを元に、アクセス制御ポリ シーに基づいてアクセス制御を⾏う ◦ 例: プレミアムプランに紐づいたライセンス → 仕訳承認画⾯を表⽰
31. 　 どうやってマジ価値を届けるの？
32. 権限管理基盤が提供する価値 ユーザーにとって • どのプロダクトでも業務に沿って安全かつ簡単に権限を運⽤できる freee の開発者にとって • 権限制御を基盤に任せ、⼿軽で安全に導⼊‧運⽤‧拡張できる プロダクトの企画者にとって • プロダクトの権限制御を素早くリーズナブルに提供できる
33. 権限管理基盤が提供する価値 ユーザーにとって • どのプロダクトでも業務に沿って安全かつ簡単に権限を運⽤できる freee の開発者にとって • 権限制御を基盤に任せ、⼿軽で安全に導⼊‧運⽤‧拡張できる プロダクトの企画者にとって • プロダクトの権限制御を素早くリーズナブルに提供できる すべて「プロダクトに権限管理基盤を使ってもらう」ことで価値が届く！
34. 例: LBAC / ライセンスベースアクセス制御を導⼊した場合 • プロダクトはアクセス制御ポリシーを考えるだけで、ユーザーの契 約プランに紐づいたライセンスに応じたアクセス制御ができる OK
 NG
 ×
 プレミアムプラン スタンダードプラン
35. 例: LBAC / ライセンスベースアクセス制御を導⼊した場合 開発者 プロダクト企画者 新プランで使う機能を考えるだけ！ 権限制御開発が簡単！ 簡単にプランを作れるから、ユーザーに 嬉しいプランがたくさん考えられるぞ！ ⾃分たちにあった プランが選べる！ freee ユーザー
36. 権限管理基盤が提供する価値 ユーザーにとって • どのプロダクトでも業務に沿って安全かつ簡単に権限を運⽤できる freee の開発者にとって • 権限制御を基盤に任せ、⼿軽で安全に導⼊‧運⽤‧拡張できる プロダクト設計する⼈にとって • プロダクトの権限制御を素早くリーズナブルに提供できる
37. 多様‧多層なアクセス制御の提供が価値を広げる • 権限管理基盤が提供する多様‧多層なアクセス制御とその品質 = プロダクトが提供できる権限制御 多層なアクセス制御 多様なアクセス制御 ロール ライセンス …
38. 基盤を導⼊ → 基盤がパワーアップするほどマジ価値が広がるよ！ 多層なアクセス制御 多様なアクセス制御 ロール ライセンス …
39. 権限管理基盤の価値は、 「プロダクトに権限管理基盤を使ってもらう」 ことで届く！
40. 社内の基盤チームならではの部分もあるよ！ • 利⽤ユーザーである開発者の slack からフィードバックを得る • 基盤チームがプロダクトを触って直接導⼊を進めることも • 導⼊作業を通じた気づきを得て基盤に⾜りない点を把握 ◦ 結果、安全な導⼊ができるような追加開発を⾏った事例も
41. 　 01 freee の権限管理基盤とは 02 権限管理基盤のマジ価値 03 マジ価値が届くまで 04 権限管理基盤のこれから ⽬次
42. 権限管理基盤の価値がユーザーに届くまで リリース
 freee ユーザー
 freee 内
 プロダクト リリース
 導入
 権限制御機能

43. 基盤機能開発
 基盤導入開発
 権限管理基盤の価値がユーザーに届くまでのフェーズ 新機能企画
 機能開発
 基盤QA
 導入QA
 導入開発
 開発‧QA でフェーズに合わせた価値を提供する プロダクト リリース
 導入
 権限制御機能

44. 　 基盤機能開発
45. 基盤開発フェーズ 基盤機能開発
 基盤導入開発
 新機能企画
 機能開発
 基盤QA
 導入QA
 導入開発
 プロダクト リリース
 導入
 権限制御機能

46. 機能開発 • 多様‧多層なアクセス制御を実現する開発 多層なアクセス制御 多様なアクセス制御 ロール ライセンス …
47. 開発の価値を作る • バグがセキュリティリスクに繋がる • 共通基盤としてのパフォーマンスリスクを引き起こす • 導⼊時の漏れが権限制御機能設計の漏れに繋がる キーワード: shift-left • なぜ shift-left しやすいのか？ ◦ API ベースだから ◦ 基盤として提供するドメインを明確にしている。だからデモベースの CI でテストができるよ • どういうテストをしているか？ ◦ テスト内容の話 ▪ 機能観点 ▪ プロダクト導⼊観点
48. • セキュリティインシデントに繋がる ◦ ⾒れてはいけない⼈や⾒てほしくない⼈のデータが⾒れてしまう ◦ サービスの信頼も落ちてしまう • 多くのサービスに影響がある ◦ 基盤起因で他サービスが障害になる可能性がある なぜ権限管理基盤で品質が重要なのか
49. 基盤開発フェーズでのポイント   QA対象は、権限管理基盤のみ！プロダクトは対象外 1   テスト準備‧実施は、ほぼすべてAPI経由で実施 2   基盤開発フェーズで、QAやるといいことがたくさん 3
50. • 権限を通してどんなユーザー体験を提供するかは、プロダクトによって異なる。 ◦ 特定のプロダクトを介したQAをしたとしても、 権限管理基盤での⼀部の機能しか利⽤しないという場合がある • 対象を権限管理基盤に絞ることで、シフトレフトすることができる。 権限管理基盤が提供する権限制御機能 プロダクトAが 利⽤する権限制御 プロダクトBが 利⽤する権限制御   QA対象は、権限管理基盤のみ！プロダクトは対象外 1
51. • ユーザ作成などのテスト準備や 権限管理基盤が提供する機能もAPI経由でテストを実施。 OK
 NG
 ×
 管理者 メンバー …. … … アクセス制御ポリシー 画⾯制御 テスト対象：権限管理基盤 エンドポイント保護 設定ファイルの更新   テスト準備‧実施は、ほぼすべてAPI経由で実施 2
52. 基盤機能開発 • プロダクトの変更に強いので、テストをシフトレフトできる。 • ⾃動テストとして実⾏しているので安⼼安全に開発を進めることができる。 Eng
 Pull Request Merge Release 基盤QA
 リグレッションテスト 機能テスト 機能テストを含む リグレッションテスト   テスト準備‧実施は、ほぼすべてAPI経由で実施 2
53. • これまでプロダクトチームで細かな権限のテストが不要になる。 • リリース前の脆弱性診断で⾒つかっていた権限による脆弱性は、 権限管理基盤を導⼊していれば早期に検知‧対応できる。 • 基盤開発フェーズでQAできると安⼼安全にリリースが早くできる。   基盤開発フェーズで、QAやるといいことがたくさん 3
54. • 権限を通じて提供するユーザー体験は、プロダクトごとで異なる。 • テスト対象を絞ることで、シフトレフトすることができる。 基盤開発フェーズ：まとめ   QA対象は、権限管理基盤のみ！プロダクトは対象外 1   テスト準備‧実施は、ほぼすべてAPI経由で実施 2   基盤開発フェーズで、QAやるといいことがたくさん 3 • プロダクトの変更に強いので、テストもシフトレフトしやすい。 • ⾃動テストとして実⾏しているので安⼼安全に開発が進められる。 • 導⼊開発フェーズで、細かな権限周りのテストが不要になる。 • 権限周りの脆弱性が早期に発⾒‧対応でき、リリースが早くできる。
55. 　 基盤導⼊開発
56. 導⼊開発フェーズ 基盤機能開発
 基盤導入開発
 新機能企画
 機能開発
 基盤QA
 導入QA
 導入開発
 プロダクト リリース
 導入
 権限制御機能

57. 導⼊開発フェーズでのポイント   プロダクトに合ったアクセス制御ポリシー設計が重要 1   プロダクトチームにもQAを実施してもらう 2   設定ファイルの記載漏れに気付ける仕組みを⽤意する 3
58. • 権限制御を利⽤すること⾃体は簡単 ◦ 設定ファイルを⽤意するだけで利⽤可能 • 権限制御を安全に導⼊するのが難しい ◦ 適切なポリシー設計のためには必要なこと ▪ プロダクトのドメイン知識 ▪ 権限ドメインの知識が必要 ◦ 安全に導⼊するための品質担保が重要！ プロダクトと基盤の連携が必要   プロダクトに合ったアクセス制御ポリシー設計が重要 1
59. • アクセス制御ポリシーが適⽤されているか ◦ プロダクトに設定したアクセス制御ポリシーが アプリ側で正しく適⽤されているかをテストする • 設定ファイルにエンドポイント∕機能の記載漏れがないか ▪ プロダクト側のリグレッションテストを実施することで 重篤度の⾼い機能において記載漏れがないことをテストする   プロダクトチームにもQAを実施してもらう 2
60. 通常 安全 プロダクト処理前に拒否 判定だけして結果を プロダクトに転送   設定ファイルの記載漏れに気付ける仕組みを⽤意する 3
61. エンドポイント保護を安全に導⼊するための例 通常 安全 プロダクト処理前に拒否 判定だけして結果を プロダクトに転送
62. • 設定ファイルを⽤意するだけで、権限制御機能は利⽤できるようになる • 適切なポリシー設計のために、プロダクトと権限管理基盤の連携が必要。 導⼊開発フェーズ：まとめ   プロダクトに合ったアクセス制御ポリシー設計が重要 1   プロダクトチームにもQAを実施してもらう 2   設定ファイルの記載漏れに気付ける仕組みを⽤意する 3 • プロダクトの設定ファイル⾃体の正しさは、導⼊開発QAで担保する • プロダクト側でアクセス制御ポリシーが適応しているかのテストを実施 • 設定ファイルの記載漏れは、リグレッションテストを実施して洗い出す • 設定ファイルの記載漏れは完全に防げない • 仮に記載が漏れていたとしても、気がつける仕組み‧体制にしている
63. 　 01 freee の権限管理基盤とは 02 権限管理基盤のマジ価値 03 マジ価値が届くまで 04 権限管理基盤のこれから ⽬次
64. 基盤機能∕導⼊開発で⽬指す世界 • 機能開発 ◦ freee 独⾃のユーザー属性に合わせた多様‧多層なアクセス制御を想定 • 導⼊開発 ◦ 利⽤者が簡単に誰の⼿も借りずに基盤を導⼊できる世界を⽬指す ◦ SLI/SLO などの品質基準の設定
65. 参考: freee Developers Hub 関連ページ • freee の権限管理基盤マイクロサービスの今を語ろう！ ◦ https://developers.freee.co.jp/entry/authorization-management-micros ervice • freee 権限管理基盤を開発するチームの今を語ろう！ ◦ https://developers.freee.co.jp/entry/authorization-management-develo pment-team • 権限管理基盤マイクロサービスで⾏っているQA活動について ◦ https://developers.freee.co.jp/entry/freee-qa-advent-calendar-day2 • QAエンジニアからSEQへのキャリアパスについて考える ◦ 発表者の記事。SEQ としての取り組みが権限管理基盤に反映されている ◦ https://developers.freee.co.jp/entry/freee-qa-advent-calendar-day1