マルチテナントSaaSを正しく作りたい! (セキュリティ編)

1K Views

June 14, 25

スライド概要

2025.06.14 クラメソさっぽろIT勉強会 (仮) #10: セキュリティ

profile-image

札幌の隅っこにすんでるバックエンドエンジニア。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

マルチテナントSaaSを正しく作りたい! (セキュリティ編) クラメソさっぽろIT勉強会 (仮) #10: セキュリティ 1

2.

名前 もりやま ロール バックエンドエンジニア 趣味 ゲーム音楽、キャンプ、筋トレ 近況 やっとAWS認定試験、全冠! 転職活動中です。 2

3.

先に宣伝!(2025/6/18(水) 第3回 AWS初心者LT会in札幌) AWSを始めたばかりの方や、若手の方など同じ立場の方と話してみませんか? AWS初心者のためのLT会を開催します! ✅LTをしてみたいけど、なかなか勇気が出ない… ✅AWSに関わる人と話してみたい! ✅AWSを触り始めたばかりで何から学んだらいいかわからない… ・・・という方がLTをしたり、聞いたり、話したりする会です! 3

4.

先に宣伝!(AWS初心者LT会in札幌スピンオフ~AWS BuilderCards大会~) 7月後半に実施予定です!近日Connpass公開します! 4

5.

今回のテーマ 5

6.

今回のテーマ マルチテナントSaaSの作っていく上での必要な「認可」について。 (2025/03 JAWS-UG札幌勉強会のLTの続編となります。 ) 6

7.

今回のテーマ なんで「正しく」作るの? 7

8.

「正しくない」マルチテナントSaaS 会社が潰れる。 (個人情報漏洩など) 8

9.

その前に・・・ ところで、R7春期 情報処理安全支援確保士試験、 受験しましたか? 9

10.

その前に・・・ 午後難しかったですね・・・! 10

11.

難化してる? 11

12.

今回のテーマ びっくりした問題を紹介! 12

13.

通信解析ツールを挟んだTLS HandShakeのシーケンス図 13

14.

ネットワークスペシャリストの試験・・・? CONNECT www.a-sha.co.jp HTTP ステータスコード 200(OK) Client Hello Server Hello Certificate Certificate Verefy Finished Finished GET /campain/■■■ HTTP/1.1 GET /campain/■■■ HTTP/1.1 HTTP 200 HTTP 200 14

15.

クエリパラメータで指定したキャンペーンサイトを表示するスマホアプリ 15

16.

www.a-sha.co.jpだったら認証トークンを返す仕組み 16

17.

攻撃者のk-sha.co.jpを使ってどう奪取する? 17

18.

正解? a-sha.co.jp.k-sha.co.jp 18

19.

正解 a-sha.co.jp.k-sha.co.jp ここサブドメイン。 。 。 19

20.

本題に戻ります! 20

21.

マルチテナントSaaSとセキュリティ(認証/認可) 厳格なテナント分離 (Isolation) 他社のデータに絶対にアクセスさせない! スケーラビリティ (Scalability) テナントやテナント内の権限・ユーザが増えても、破綻しないこと。 21

22.

マルチテナントSaaSとセキュリティ(認証/認可) 厳格なテナント分離 (Isolation) 他社のデータに絶対にアクセスさせない! スケーラビリティ (Scalability) テナントやテナント内の権限・ユーザが増えても、破綻しないこと。 ABAC(属性別アクセスコントロール)で対応してみる! 22

23.

ABAC(Attribute-Based Access Control)って? 「誰が」「何を」「どうする?」を複数指定できる認可の仕組み。 例:ロール別の認可の場合(RBAC) 「課長」は、決済情報を編集することができる。 例:属性別の認可の場合(ABAC) 経理部または財務部の課長以上の正社員が、多要素認証済みで、 平日業務時間中に、社内ネットワークから会社支給PCを使用している場合、 100万円以下の決済情報を編集することができる。 23

24.

ABAC(Attribute-Based Access Control)って? 複数で組みわせると、複雑な認可管理がしやすい 例:ロール別の認可の場合(RBAC) テナントAの運用者(日中) テナントAの管理者(日中) テナントBの運用者(日中) テナントBの管理者(日中) ・・・ テナントAの運用者(夜間) テナントAの管理者(夜間) テナントBの運用者(夜間) テナントBの管理者(夜間) ・・・ 例:属性別の認可の場合(ABAC) テナント種別 権限(管理者、運用者) 勤務体系 24

25.

+考慮点 リソース操作指示を安全な方法で指示したい! 25

26.

+考慮点 リソース操作指示を安全な方法で指示したい! 改ざん可能なリクエストパラメタNG! 26

27.

マルチテナントSaaSの「認可」アプローチ 紹介する3アプローチ 1.JWTカスタムクレーム認可 2.クライアント証明書 3.Amazon Verified Permissions 27

28.

マルチテナントSaaSの「認可」アプローチ 紹介する3アプローチ 1.JWTカスタムクレーム認可 2.クライアント証明書 3.Amazon Verified Permissions 28

29.

JWTカスタムクレーム認可 概要 ユースケース 使用技術 JWT(IDトークン)に含まれるカスタムクレームで認可 OAuth/OIDCによる認証があるケース Cognito ユーザプール/IDプール 29

30.

JWT(IDトークン)とは? ・JWT(JSON Web Token)は、JSON形式でエンコードされた情報 (デジタル署名付き!) ・IDトークンはユーザの属性情報が入っている。 30

31.

JWT(IDトークン)とは? ・JWT(JSON Web Token)は、JSON形式でエンコードされた情報 (デジタル署名付き!) 改ざん不可な属性をBackendへ渡せる! 31

32.

処理イメージ 32

33.

DynamoDB接続 custom:tenant_idをSTS(一時的な認証情報)内で利用できるようにする。 33

34.

DynamoDB接続 IDプールから払い出すロールにて、 トークン内の「custom:tenant_id」を認可条件として利用 PK=cunstom:tenant_idのレコードだけ認可! 34

35.

JWTカスタムクレームを使った疑似RLS 「custom:tenant_id」を セッション変数@current_tenant_idに設定し、擬似RLSを実現したり。 35

36.

マルチテナントSaaSの「認可」アプローチ 紹介する3アプローチ 1.JWTクレームベース認可 2.証明書サブジェクト認可 3.Amazon Verified Permissions 36

37.

クライアント証明書のサブジェクト認可 概要 クライアント証明書に含まれるサブジェクトの属性で認可 ユースケース M2M認証 使用技術 mTLS,RLS 37

38.

クライアント証明書のサブジェクト 38

39.

クライアント証明書のサブジェクト 改ざん不可な属性をBackendへ渡せる! 39

40.

処理イメージ クラアント証明書のサブジェクトをバックエンドにリクエスストヘッダで伝搬 X-Client-Cert-Subject:C=JP,ST=Hokkaido,L=Sapporo,O=MyCompany,OU=Finance,CN=tenant-001 40

41.

マルチテナントSaaSの「認可」アプローチ 紹介する3アプローチ 1.JWTクレームベース認可 2.クライアント証明書 3.Amazon Verified Permissions 41

42.

Amazon Verified Permissions? きめ細かな認可を実現するフルマネージド Cedar サービス 認可のみ アプリとの分離 Cedar言語 認証は他のサービスが担当 認可処理をアプリケーショ ンロジックから分離可能 Cedar言語を使った きめ細やかな認可 42

43.
[beta]
Cedar言語?
「いつ」、「誰が」「何を」「どのように」「許可/拒否」を設定可能

permit(
principal is MyApp::User,
action == MyApp::Action::"view",
resource is MyApp::Photo
)
when {
resource.owner == principal
};

44.
[beta]
誰(User)が

permit(

principal is MyApp::User,

action == MyApp::Action::"view",
resource is MyApp::Photo

)
when {
resource.owner == principal
};

44

45.
[beta]
どのリソース(Photo)に

permit(
principal is MyApp::User,
action == MyApp::Action::"view",

resource is MyApp::Photo

)
when {
resource.owner == principal
};

45

46.
[beta]
何を(view)を許可する

permit(
principal is MyApp::User,

action == MyApp::Action::"view",

resource is MyApp::Photo

)
when {
resource.owner == principal
};
46

47.
[beta]
いつ(リソース(Phone)の所有者=プリンパル(ユーザ)の場合)

permit(
principal is MyApp::User,
action == MyApp::Action::"view",
resource is MyApp::Photo
)
when {
};

resource.owner == principal

47

48.

これも。。 例:属性別の認可の場合(ABAC) 経理部または財務部の課長以上の正社員が、多要素認証済みで、 平日業務時間中に、社内ネットワークから会社支給PCを使用している場合、 100万円以下の決済情報を編集することができる。 48

49.

できそう! permit( principal is 経理部または財務部の課長以上の正社員 action == 編集 resource is 決済情報 ) when { }; 多要素認証済、 かつ、平日営業時間中 かつ、会社支給PCの場合 かつ、決済情報金額が100万円以下 49

50.

実装例 SDKで認可ができるので、どこでも。 50

51.

実装例 SDKで認可ができるので、どこでも。 ②バックエンドでも ①API呼び出し時 51

52.

Amazon Verified Permissions vs Cognito IDプール Verified Permissions Cognito IDプール 言語 Cedar IAMポリシー(JSON) 粒度 細かい 粗め 更新 リアルタイム反映 トークン期間中は固定 用途 アプリ内認可 AWSサービスアクセス認可 例 自分の写真のみ閲覧認可 Dyanamo DBの参照認可 52

53.

まとめ セキュリティ、楽しい! 53