OWT2017jp - Least Privilege

OWT2017jp
Least Privilege Design and Implementation
by 長山哲也, 神戸デジタル・ラボ

Transcript

1. 最小権限の具体的な実現方法 長山哲也 （株）神戸デジタル・ラボ
2. あなた誰？ 長山 哲也 所属 株式会社神戸デジタル・ラボ セキュリティソリューション事業部 セキュリティ運用支援チーム リーダー 経歴 • Sierでの金融機関システムのインフラを担当。セキュリ ティ要件定義を作成したことでセキュリティに興味を持つ • KDLにてWebアプリケーション/プラットフォーム脆弱性 診断/標的型攻撃メール訓練を担当 • その後、コンサルタントとしてリスク分析、セキュリティ 要件定義支援、ポリシー策定支援、セキュア開発支援等を 実施 • コンサルタントと並行してASPの企画開発主導 言語 Python
3. 最も伝えたいこと 情報・データ起点権限設計しましょう
4. アジェンダ • 最小権限とは • 最小権限の重要性と難しさ • 何を守ろうとしているのか • 権限設計をするには • 実装するには • どのように検証すべきか • 最小権限を維持するには
5. テーマの対象 • Webアプリケーションの権限設計 • サーバ、OSの権限設計 • 組織運用上の権限設計
6. 権限 最小権限とは アクセス制御を設計する際は、ユーザーやシステム・コンポーネン トごとに操作の実行に要求される最低限の権限を、最低限の期間だ け割り当てる必要があります 範 囲 期間 OWASP Top 10 Proactive Controls 2016 Japanese P19 <https://www.owasp.org/images/a/a8/OWASPTop10ProactiveControls2 016-Japanese.pdf >
7. 最小権限の重要性と難しさ - ビジネスとの結びつきが強い - ツールでは脆弱性を見つけにくい - 脆弱性を見つけても修正しにくい
8. 最小権限の重要性と難しさ - ビジネスとの結びつきが強い 権限設計に失敗した場合利用プラン自体を見直す必要がでる 機能 無料 ユーザ 有料 ユーザ 管理者 ユーザ 対応す る画面 A ◯ ◯ ◯ 画面1 画面2 B ◯ ◯ ◯ 画面4 C × ◯ ◯ 画面1 D × × ◯ 画面7
9. 最小権限の重要性と難しさ - ツールでは脆弱性を見つけにくい <script>alert(‘XSS’)</script> Web アプリケーション GET http://…/?role=trial GET http://…/?role=manager 無料ユーザ用 の画面 管理者ユーザ用 の画面 Web アプリケーション XSS！ レスポンス違 うけど OK?NG?
10. 最小権限の重要性と難しさ - 脆弱性を見つけても修正しにくい Q .代行は全てのコンテンツを 操作していいのか？ A社用 コンテンツ1 A社用 コンテンツ2 B社用 コンテンツ1 C社用 コンテンツ1 コンテンツ マネージャー マネージャー 代行
11. 最小権限の重要性と難しさ - 脆弱性を見つけても修正しにくい A1.代行は自社内の限られた者 が使うため操作して良い A2.代行は委託先も利用するた め全て操作できてはいけない A3.そもそもどこまで使うか想 定していない 後一週間で、、 • そもそも権限設定の機能なかったから作らなきゃ • 権限での絞り込み機能を作らなきゃ A社用 コンテンツ1 A社用 コンテンツ2 B社用 コンテンツ1 C社用 コンテンツ1 コンテンツ マネージャー マネージャー 代行
12. 最小権限の重要性と難しさ ビジネスと結びつきが強いにも関わらず、脆弱性 を見つけにくく、見つかった時の影響が大きい 影響の大きさ • 失敗すると不必要に許可された権限を利用して情報漏 洩を起こすことが可能、利用プランやサービスメ ニューも見直すかも • 脆弱性診断で見つけるには手間が必要だし、見つかっ たところで修正するための工数が必要
13. 最小権限を実現するために公開されている情報 - IPAの場合 - OWASPの場合
14. 最小権限を実現するために公開されている情報 - IPAの場合 要約：外部のパラメータを利用してアクセス制御しないように！ Web アプリ ケー ション http://…/?user=naga http://…/?user=yama 無料ユーザ用 の画面 管理者ユーザ用 の画面 IPA 安全なWebサイトの作り方 P46 – P47 <https://www.ipa.go.jp/files/000017316.pdf>
15. 最小権限を実現するために公開されている情報 – OWASPの場合 6:適切なアクセス制御の実装 • すべてのリクエストがアクセス制御を通るようにする • アクセス制御のデフォルトは「拒否」 • 最小権限の原則 • アクセス制御をプログラムにハードコーディングしない • アクティビティに基づいて記述する • アクセス制御には、サーバー側の信頼できるデータを使う OWASP Top 10 Proactive Controls 2016 Japanese P18 – P20 <https://www.owasp.org/images/a/a8/OWASPTop10ProactiveControls2 016-Japanese.pdf>
16. 最小権限を実現するために公開されている情報 実装上やらなければいけないこと 設計上やらなければいけないこと
17. 何を守ろうとしているのか - どんな攻撃があるのか - 守るべき対象
18. 何を守ろうとしているのか – どんな攻撃があるのか • 認証後の画面に未認証状態でアクセスする • 認証後のみ閲覧可能なコンテンツを未認証状態でダウン ロードする • 別の権限を持つユーザ用に用意した画面にアクセスする • 権限設定をしているパラメータを改ざんする • 別のユーザのデータが取得される
19. ID PASS https://example.com/login 何を守ろうとしているのか – どんな攻撃があるのか 認証後の画面に未認証状態でアクセスする →誰でも認証後のユーザのみが閲覧できる情報が見える https://example.com/mypage 脆弱性を突いたルート 直接URLにアクセスして 認証回避を行う 正常なルート
20. 何を守ろうとしているのか – どんな攻撃があるのか 認証後のみ閲覧可能なコンテンツを未認証状態でダウンロードする →公開領域にあるので誰でも情報が見える ID PASS https://example.com/login 正常なルート PDF https://example.com/guide.pdf 脆弱性を突いたルート
21. 何を守ろうとしているのか – どんな攻撃があるのか 別の権限を持つユーザ用に用意した画面にアクセスする →認証後において特定のユーザのみが閲覧可能な情報を 認証されたユーザであれば誰でも見れる ID PASS 正常なルート 脆弱性を突いたルート https://example.com/ manage/?id=27 https://example.com/ mypage/?id=43 違うIDを指定することで アクセス制御を強制する
22. 何を守ろうとしているのか – どんな攻撃があるのか 権限設定をしているパラメータを改ざんする →特定の権限を持つユーザのみが閲覧可能な情報が 認証されたユーザであれば誰でも見れる ID PASS https://example.com/manager/ Cookie”role:manager” https://example.com/mypage/ Cookie”role:trial” 違う権限を指定することで アクセス制御を強制する 正常なルート 脆弱性を突いたルート
23. 何を守ろうとしているのか – どんな攻撃があるのか 別のユーザのデータが取得される →設計ミス、実装ミスで全データが取得される id コンテンツ 所有者 1 コンテンツA Tokyo 4 コンテンツC Kansai 8 コンテンツD Nagoya 12 コンテンツF Tokyo 15 コンテンツK Tokyo 22 コンテンツM Kansai コンテンツAから コンテンツMまで表示。。
24. 何を守ろうとしているのか – 守るべき対象 画面・UI データ （ファイル、 データベース） 守りたいのは 情報（データ） データ中心に アクセス権限を考える
25. 小ネタ：リスクアセスメントでも一緒 情報資産の 洗い出し 脅威の明確化 リスクアセスメント 情報資産の特定をして 誰がアクセス可能かで 脅威や脆弱性を探る 権限設計 システムで扱うデータを 特定して誰がアクセス して良いかを探る ≒
26. 権限設計をするには - データとその特性の洗い出し - 操作方法の検討
27. データとその特性の洗い出し - 扱うデータの特定 - データのライフサイクルの検討 - データの操作権の特定
28. データとその特性の洗い出し 架空のコンテンツ管理システムを題材にしてみる コンテンツ管理ASP「コンテンチャー」 ユーザ スペース ユーザ スペース ユーザ スペース システム 管理者 有料 ユーザ 無料 ユーザ • ユーザは契約したらスペース にコンテンツをアップロード して業務をする • システム管理者はアップロー ドしたコンテンツを分析する
29. データとその特性の洗い出し – 扱うデータの特定 PDF Image ER図の作成 扱うファイル の洗い出し データベースに格納するデータ、ストレージに格納するデータ、 それぞれ洗い出す
30. データとその特性の洗い出し – データのライフサイクルの検討 サービス提供期間に紐づきやすいためアカウント関連のデータは、 その他のデータとは分けて考える アカウント 関連のデータ その他のデータ （アカウント関連のデータ やサービス提供期間に依存） その他のデータ （システム稼働期間に依存） サービス提供期間 システム稼働期間
31. データとその特性の洗い出し – データのライフサイクルの検討 作成契機 ・システム管理者が 申請の度に作成 ・管理権限のある ユーザが作成 削除契機 ・ユーザが任意の タイミングで削除 ・契約終了後削除 アカウント関連のデータの検討
32. データとその特性の洗い出し – データのライフサイクルの検討 その他のデータの検討 作成契機 システム管理者が一 カ月に一回作成 削除契機 分析完了後削除 作成契機 契約期間中にユーザ が任意のタイミング で作成 削除契機 ・ユーザが任意の タイミングで削除 ・契約終了後削除 先にアカウント関連 のデータのライフサ イクルを考えておく と発想しやすい
33. データとその特性の洗い出し – データの操作権の特定 1. 認証の有無によってアクセスできるかどう かを検討する 2. 認証後のアクセスするデータのアクセスさ れる単位を検討する
34. データとその特性の洗い出し – データの操作権の特定 未認証でも アクセス できる範囲 認証後に アクセス できる範囲 認証後でないと アクセスできない 公開領域に設置しない 未ログイン時の画面に表示しない ＝
35. データとその特性の洗い出し – データの操作権の特定 以下のどれにあたるか？ • ユーザ単位で管理 • グループ単位で管理 • 権限単位で管理 • 上記組み合わせで管理 レコードの操作 単位を把握する 操作権限を渡す 対象を理解する ＝
36. データとその特性の洗い出し – データの操作権の特定 id name description group_id 1 コンテンツA …… Tokyo 4 コンテンツC …… Kansai 8 コンテンツD …… Nagoya 12 コンテンツF …… Tokyo id name description user_id 1 コンテンツA …… sSjp00231 4 コンテンツC …… Sato_python29 8 コンテンツD …… sSjp00231 12 コンテンツF …… Sato_python29 グループ 単位の テーブル ユーザ 単位の テーブル 検討結果によって参照するためのカラムが増える
37. 操作方法の検討 - Howを考える - シーケンス図で検証する
38. 操作方法の検討 – Howを考える 作成 契機 システム管理者が一 カ月に一回作成 認証後の管理者ユーザのみがア クセス可能な画面から作成する 削除 契機 分析完了後削除 システムで定期的にバッチに よって削除 作成 契機 契約期間中にユーザ が任意のタイミング で作成 認証後の有料ユーザのみがアク セス可能な画面から作成する 削除 契機 ユーザが任意の タイミングで削除 認証後の有料ユーザのうち管理 権限のあるユーザのみがアクセ ス可能な画面から削除 契約終了後削除 システムで定期的にバッチに よって削除 具体的なインターフェース を考える
39. 操作方法の検討 – Howを考える ユーザ ユーザ機能 管理機能 管理者 一時ユーザ ユーザ認証 登録用一時URLメール送信 一時URL確認 アカウント関連のデータを利用した 認証についてはシーケンス図等でHowを検証 削除契機の 新たな発見 一時ユーザが 必要になった
40. 実装するには - フレームワークのアクセス制御機能を利用 - その他参考となる情報
41. 実装するには – フレームワークのアクセス制御機能を利用 アクセス制御機能(ACL)を利用すると以下のようなことが簡単に実現可能 1.ログイン有無による制限 2.ページ単位のアクセス許可・禁止 残りのユーザ種別によるデータの取得のみ実装すれば良くなる Webアプリケーション cookieにてセッショ ンIDを送信 id content group_id 1 コンテンツA Tokyo 4 コンテンツC Kansai 8 コンテンツD Nagoya 12 コンテンツF Tokyo 15 コンテンツK Tokyo 22 コンテンツM Kansai Tokyoグループの データだけ受信 セッションに紐づく ユーザIDや権限の取得 取得したユーザIDや権 限に合致したデータの 取得
42. 実装するには – その他参考となる情報 ▪IPA セキュアプログラミング講座 第2章アクセス制御 アクセス認可 <https://www.ipa.go.jp/security/awareness/vendor/ programmingv2/web.html> ▪OWASP OWASP Top10 ProactiveControl2016 <https://www.owasp.org/images/a/a8/ OWASPTop10ProactiveControls2016-Japanese.pdf > 12の事例に学ぶWebアプリケーションのアクセス制御 <https://speakerdeck.com/owaspjapan/12-case-studies-for-the- access-controls-of-web-application-number-appsecapac2014>
43. どのように検証すべきか - テストコードに含める - コードから権限表を生成する
44. どのように検証すべきか – テストコードに含める 設計者や開発者：結果が正しいか判断可能 第三者の診断担当者：権限表がない限り推測での判断となる A社用 コンテンツ1 A社用 コンテンツ2 B社用 コンテンツ1 C社用 コンテンツ1 権限X 権限Y 開発者 第三者の 診断担当者
45. どのように検証すべきか – コードから権限表を生成する ドキュメンテーションとテストコード記述のコストを抑える View Model Contro ler 機能名 画面名 無料 ユーザ 有料 ユーザ 管理者 ユーザ コ ン テ ン ツ 管 理 参照 ◦ ◦ ◦ 作成 × ◦ ◦ 削除 × ◦ ◦ ユ ー ザ 管 理 ユーザ 作成 × × ◦ パス ワード 編集 × × ◦ スクリプト
46. 最小権限を維持するために - コードから権限表を再生成する
47. どのように検証すべきか – コードから権限表を生成する 権限設計をユーザ視点とデータ視点双方から確認しやすくなる 機能名 画面名 無料 ユーザ 有料 ユーザ 管理者 ユーザ コ ン テ ン ツ 管 理 参照 ◦ ◦ ◦ 作成 × ◦ ◦ 削除 × ◦ ◦ ユ ー ザ 管 理 ユーザ 作成 × × ◦ パス ワード 編集 × × ◦
48. まとめ 設計 システムで扱うデータとその特性を洗い 出して、データの権限設計を行う 実装 フレームワークの機能を利用して、 自前でのアクセス制御を減らす 検証 テストコード内で権限設計を検証する 維持 権限表を自動生成させて権限設計の面倒 なドキュメンテーション作業を減らす