OWT2017jp Least Privilege Design and Implementation by 長山哲也, 神戸デジタル・ラボ
最小権限の具体的な実現方法長山哲也（株）神戸デジタル・ラボ
View Slide
あなた誰？長山 哲也所属株式会社神戸デジタル・ラボセキュリティソリューション事業部セキュリティ運用支援チーム リーダー経歴• Sierでの金融機関システムのインフラを担当。セキュリティ要件定義を作成したことでセキュリティに興味を持つ• KDLにてWebアプリケーション/プラットフォーム脆弱性診断/標的型攻撃メール訓練を担当• その後、コンサルタントとしてリスク分析、セキュリティ要件定義支援、ポリシー策定支援、セキュア開発支援等を実施• コンサルタントと並行してASPの企画開発主導言語 Python
最も伝えたいこと情報・データ起点権限設計しましょう
アジェンダ• 最小権限とは• 最小権限の重要性と難しさ• 何を守ろうとしているのか• 権限設計をするには• 実装するには• どのように検証すべきか• 最小権限を維持するには
テーマの対象• Webアプリケーションの権限設計• サーバ、OSの権限設計• 組織運用上の権限設計
権限最小権限とはアクセス制御を設計する際は、ユーザーやシステム・コンポーネントごとに操作の実行に要求される最低限の権限を、最低限の期間だけ割り当てる必要があります範囲期間OWASP Top 10 Proactive Controls 2016 Japanese P19016-Japanese.pdf >
最小権限の重要性と難しさ- ビジネスとの結びつきが強い- ツールでは脆弱性を見つけにくい- 脆弱性を見つけても修正しにくい
最小権限の重要性と難しさ - ビジネスとの結びつきが強い権限設計に失敗した場合利用プラン自体を見直す必要がでる機能 無料ユーザ有料ユーザ管理者ユーザ対応する画面A ◯ ◯ ◯画面1画面2B ◯ ◯ ◯ 画面4C × ◯ ◯ 画面1D × × ◯ 画面7
最小権限の重要性と難しさ - ツールでは脆弱性を見つけにくいalert(‘XSS’)WebアプリケーションGET http://…/?role=trialGET http://…/?role=manager無料ユーザ用の画面管理者ユーザ用の画面WebアプリケーションXSS！レスポンス違うけどOK?NG?
最小権限の重要性と難しさ - 脆弱性を見つけても修正しにくいQ .代行は全てのコンテンツを操作していいのか？A社用コンテンツ1A社用コンテンツ2B社用コンテンツ1C社用コンテンツ1コンテンツマネージャーマネージャー代行
最小権限の重要性と難しさ - 脆弱性を見つけても修正しにくいA1.代行は自社内の限られた者が使うため操作して良いA2.代行は委託先も利用するため全て操作できてはいけないA3.そもそもどこまで使うか想定していない後一週間で、、• そもそも権限設定の機能なかったから作らなきゃ• 権限での絞り込み機能を作らなきゃA社用コンテンツ1A社用コンテンツ2B社用コンテンツ1C社用コンテンツ1コンテンツマネージャーマネージャー代行
最小権限の重要性と難しさビジネスと結びつきが強いにも関わらず、脆弱性を見つけにくく、見つかった時の影響が大きい影響の大きさ• 失敗すると不必要に許可された権限を利用して情報漏洩を起こすことが可能、利用プランやサービスメニューも見直すかも• 脆弱性診断で見つけるには手間が必要だし、見つかったところで修正するための工数が必要
最小権限を実現するために公開されている情報- IPAの場合- OWASPの場合
最小権限を実現するために公開されている情報 - IPAの場合要約：外部のパラメータを利用してアクセス制御しないように！Webアプリケーションhttp://…/?user=nagahttp://…/?user=yama無料ユーザ用の画面管理者ユーザ用の画面IPA 安全なWebサイトの作り方 P46 – P47
最小権限を実現するために公開されている情報 – OWASPの場合6:適切なアクセス制御の実装• すべてのリクエストがアクセス制御を通るようにする• アクセス制御のデフォルトは「拒否」• 最小権限の原則• アクセス制御をプログラムにハードコーディングしない• アクティビティに基づいて記述する• アクセス制御には、サーバー側の信頼できるデータを使うOWASP Top 10 Proactive Controls 2016 Japanese P18 – P20016-Japanese.pdf>
最小権限を実現するために公開されている情報実装上やらなければいけないこと設計上やらなければいけないこと
何を守ろうとしているのか- どんな攻撃があるのか- 守るべき対象
何を守ろうとしているのか – どんな攻撃があるのか• 認証後の画面に未認証状態でアクセスする• 認証後のみ閲覧可能なコンテンツを未認証状態でダウンロードする• 別の権限を持つユーザ用に用意した画面にアクセスする• 権限設定をしているパラメータを改ざんする• 別のユーザのデータが取得される
IDPASShttps://example.com/login何を守ろうとしているのか – どんな攻撃があるのか認証後の画面に未認証状態でアクセスする→誰でも認証後のユーザのみが閲覧できる情報が見えるhttps://example.com/mypage脆弱性を突いたルート直接URLにアクセスして認証回避を行う正常なルート
何を守ろうとしているのか – どんな攻撃があるのか認証後のみ閲覧可能なコンテンツを未認証状態でダウンロードする→公開領域にあるので誰でも情報が見えるIDPASShttps://example.com/login正常なルートPDFhttps://example.com/guide.pdf脆弱性を突いたルート
何を守ろうとしているのか – どんな攻撃があるのか別の権限を持つユーザ用に用意した画面にアクセスする→認証後において特定のユーザのみが閲覧可能な情報を認証されたユーザであれば誰でも見れるIDPASS正常なルート脆弱性を突いたルートhttps://example.com/manage/?id=27https://example.com/mypage/?id=43違うIDを指定することでアクセス制御を強制する
何を守ろうとしているのか – どんな攻撃があるのか権限設定をしているパラメータを改ざんする→特定の権限を持つユーザのみが閲覧可能な情報が認証されたユーザであれば誰でも見れるIDPASShttps://example.com/manager/Cookie”role:manager”https://example.com/mypage/Cookie”role:trial”違う権限を指定することでアクセス制御を強制する正常なルート脆弱性を突いたルート
何を守ろうとしているのか – どんな攻撃があるのか別のユーザのデータが取得される→設計ミス、実装ミスで全データが取得されるid コンテンツ 所有者1 コンテンツA Tokyo4 コンテンツC Kansai8 コンテンツD Nagoya12 コンテンツF Tokyo15 コンテンツK Tokyo22 コンテンツM KansaiコンテンツAからコンテンツMまで表示。。
何を守ろうとしているのか – 守るべき対象画面・UI データ（ファイル、データベース）守りたいのは情報（データ）データ中心にアクセス権限を考える
小ネタ：リスクアセスメントでも一緒情報資産の洗い出し脅威の明確化リスクアセスメント情報資産の特定をして誰がアクセス可能かで脅威や脆弱性を探る権限設計システムで扱うデータを特定して誰がアクセスして良いかを探る≒
権限設計をするには- データとその特性の洗い出し- 操作方法の検討
データとその特性の洗い出し- 扱うデータの特定- データのライフサイクルの検討- データの操作権の特定
データとその特性の洗い出し架空のコンテンツ管理システムを題材にしてみるコンテンツ管理ASP「コンテンチャー」ユーザスペースユーザスペースユーザスペースシステム管理者有料ユーザ無料ユーザ• ユーザは契約したらスペースにコンテンツをアップロードして業務をする• システム管理者はアップロードしたコンテンツを分析する
データとその特性の洗い出し – 扱うデータの特定PDFImageER図の作成 扱うファイルの洗い出しデータベースに格納するデータ、ストレージに格納するデータ、それぞれ洗い出す
データとその特性の洗い出し – データのライフサイクルの検討サービス提供期間に紐づきやすいためアカウント関連のデータは、その他のデータとは分けて考えるアカウント関連のデータその他のデータ（アカウント関連のデータやサービス提供期間に依存）その他のデータ（システム稼働期間に依存）サービス提供期間システム稼働期間
データとその特性の洗い出し – データのライフサイクルの検討作成契機・システム管理者が申請の度に作成・管理権限のあるユーザが作成削除契機・ユーザが任意のタイミングで削除・契約終了後削除アカウント関連のデータの検討
データとその特性の洗い出し – データのライフサイクルの検討その他のデータの検討作成契機システム管理者が一カ月に一回作成削除契機 分析完了後削除作成契機契約期間中にユーザが任意のタイミングで作成削除契機・ユーザが任意のタイミングで削除・契約終了後削除先にアカウント関連のデータのライフサイクルを考えておくと発想しやすい
データとその特性の洗い出し – データの操作権の特定1. 認証の有無によってアクセスできるかどうかを検討する2. 認証後のアクセスするデータのアクセスされる単位を検討する
データとその特性の洗い出し – データの操作権の特定未認証でもアクセスできる範囲認証後にアクセスできる範囲認証後でないとアクセスできない公開領域に設置しない未ログイン時の画面に表示しない＝
データとその特性の洗い出し – データの操作権の特定以下のどれにあたるか？• ユーザ単位で管理• グループ単位で管理• 権限単位で管理• 上記組み合わせで管理レコードの操作単位を把握する操作権限を渡す対象を理解する＝
データとその特性の洗い出し – データの操作権の特定id name description group_id1 コンテンツA …… Tokyo4 コンテンツC …… Kansai8 コンテンツD …… Nagoya12 コンテンツF …… Tokyoid name description user_id1 コンテンツA …… sSjp002314 コンテンツC …… Sato_python298 コンテンツD …… sSjp0023112 コンテンツF …… Sato_python29グループ単位のテーブルユーザ単位のテーブル検討結果によって参照するためのカラムが増える
操作方法の検討- Howを考える- シーケンス図で検証する
操作方法の検討 – Howを考える作成契機システム管理者が一カ月に一回作成認証後の管理者ユーザのみがアクセス可能な画面から作成する削除契機分析完了後削除システムで定期的にバッチによって削除作成契機契約期間中にユーザが任意のタイミングで作成認証後の有料ユーザのみがアクセス可能な画面から作成する削除契機ユーザが任意のタイミングで削除認証後の有料ユーザのうち管理権限のあるユーザのみがアクセス可能な画面から削除契約終了後削除システムで定期的にバッチによって削除具体的なインターフェースを考える
操作方法の検討 – Howを考えるユーザ ユーザ機能 管理機能 管理者一時ユーザユーザ認証登録用一時URLメール送信一時URL確認アカウント関連のデータを利用した認証についてはシーケンス図等でHowを検証削除契機の新たな発見一時ユーザが必要になった
実装するには- フレームワークのアクセス制御機能を利用- その他参考となる情報
実装するには – フレームワークのアクセス制御機能を利用アクセス制御機能(ACL)を利用すると以下のようなことが簡単に実現可能1.ログイン有無による制限2.ページ単位のアクセス許可・禁止残りのユーザ種別によるデータの取得のみ実装すれば良くなるWebアプリケーションcookieにてセッションIDを送信 id content group_id1 コンテンツA Tokyo4 コンテンツC Kansai8 コンテンツD Nagoya12 コンテンツF Tokyo15 コンテンツK Tokyo22 コンテンツM KansaiTokyoグループのデータだけ受信セッションに紐づくユーザIDや権限の取得取得したユーザIDや権限に合致したデータの取得
実装するには – その他参考となる情報■IPAセキュアプログラミング講座第2章アクセス制御 アクセス認可programmingv2/web.html>■OWASPOWASP Top10 ProactiveControl2016OWASPTop10ProactiveControls2016-Japanese.pdf >12の事例に学ぶWebアプリケーションのアクセス制御access-controls-of-web-application-number-appsecapac2014>
どのように検証すべきか- テストコードに含める- コードから権限表を生成する
どのように検証すべきか – テストコードに含める設計者や開発者：結果が正しいか判断可能第三者の診断担当者：権限表がない限り推測での判断となるA社用コンテンツ1A社用コンテンツ2B社用コンテンツ1C社用コンテンツ1権限X権限Y開発者 第三者の診断担当者
どのように検証すべきか – コードから権限表を生成するドキュメンテーションとテストコード記述のコストを抑えるViewModelControler機能名 画面名無料ユーザ有料ユーザ管理者ユーザコンテンツ管理参照 ○ ○ ○作成 × ○ ○削除 × ○ ○ユーザ管理ユーザ作成× × ○パスワード編集× × ○スクリプト
最小権限を維持するために- コードから権限表を再生成する
どのように検証すべきか – コードから権限表を生成する権限設計をユーザ視点とデータ視点双方から確認しやすくなる機能名 画面名無料ユーザ有料ユーザ管理者ユーザコンテンツ管理参照 ○ ○ ○作成 × ○ ○削除 × ○ ○ユーザ管理ユーザ作成× × ○パスワード編集× × ○
まとめ設計 システムで扱うデータとその特性を洗い出して、データの権限設計を行う実装 フレームワークの機能を利用して、自前でのアクセス制御を減らす検証 テストコード内で権限設計を検証する維持 権限表を自動生成させて権限設計の面倒なドキュメンテーション作業を減らす
owaspjapan
hayaosuzuki
sasakitomohiro
taka2noda
yoshidashingo
whywaita
yumayabe
dzeyelid
kohbis
optim
mii3king
sakiengineer
x_ttyszk
dotmariusz
bkeepers
sachag
rasmusluckow
matthewcrist
62gerente
gr2m
shpigford
lemiorhan
edds
zakiyama