はじめに
こんにちは。脆弱性診断の業務に携わっています、かをるです。
今回はタイトルの通り、脆弱性診断における「ロール」と「データ」を考慮した準備について記事を書きました。 読んでいただけると、以下について知ることができます。
- 脆弱性診断依頼時にアカウントやデータ類を準備してといわれる理由
- 脆弱性診断における権限関係の試行の考え方の一部
本編は以下の流れで説明します。
- はじめに
- 記事にしようと思った理由
- 用語の確認
- 「ロール」を考慮したアカウントや「データ」の準備が必要な背景
- 「ロール」を考慮したアカウントや「データ」を具体的なケースで考える
- 「ロール」を考慮したアカウントの確認
- 「データ」の確認
- 「ロール」を考慮したアカウントのTips
- おわりに
記事にしようと思った理由
最近、新人の方へ「「ロール」ごとのアカウントや「データ」が不足していないか確認をしましょう」と説明しました。 診断前にこれらの確認をし、不足を事前に調整することで、診断作業の中断や追加の調整事項による納期への影響（遅延）の可能性を減らすためです。 （また、診断作業中にできるだけお客様のお手を煩わせたくないという気持ちもあります。）
なお、どのような状態を「おそらく不足でない」と判断しているかですが、以下を満たす傾向にあります。
- 診断対象の機能が利用できるアカウントやデータが存在する
- かつ、同等の「ロール（役割）」をもつアカウントが2つ以上存在している
- アカウントに結び付く「データ」の内容はそれぞれ異なる
- 「権限マトリクス」が存在する
結論だけ書くと4行ですが、新人の方への説明ボリュームは結構ありましたので、今回改めて記事にしてみようと思いました。
では、まず用語を確認しましょう。
用語の確認
ロール
私が初めて聞いたときはロールケーキのrollをイメージしたのですが…ここではrollでなくrole、「役割」のことです。
ITの分野で “role” は、利用者やシステム上の何らかの要素が持つ立場や役割を指すことが多い。
図1-1はロールのイメージを概念的に示したものです。
図上部のアイコンはリーダーというロール、図下部のアイコンはメンバーというロールだったとしましょう。 ある機能があったとして、リーダーのロールでは利用可能（〇）、メンバーのロールでは利用不可（×）のようなイメージです。
データ
耳馴染みがあるのではないでしょうか。ここでは「意味のある情報のまとまり」です。
データとは、何かを文字や符号、数値などのまとまりとして表現したもの。人間にとって意味のあるものや、データを人間が解釈した結果のことを情報と呼ぶ。
それではいよいよ本題にはいりましょう。
「ロール」を考慮したアカウントや「データ」の準備が必要な背景
脆弱性診断はレストランでの注文とは異なり「診断をしてください」「かしこまりました。疑似攻撃を行いますね。」とはなりません。 事前にお客様と診断対象を決めたり、各種契約などを経て実施となります。（ここでは調整とよびます。）
この調整作業、SSTでは調整のプロフェッショナルが診断案件ごとに担当しています。 ということで、「ロール」を考慮したアカウントや「データ」の準備についても、 調整担当がお客様と打ち合わせなどをしながら準備していますため、 私たち診断担当が脆弱性診断の作業開始時には基本的に一式そろっています。
いよいよ脆弱性診断がはじまると、「本来あるべき状態」を逸脱し、どのような悪いこと・できてはいけないことができるのかを探していきます。 ここで「本来あるべき状態」とは、想定される利用方法で機能を利用し、想定される結果となった状態を指します。 基準がないのに逸脱もなにもないので、この「本来あるべき状態」を考え定めるところからはじまります。
ですがまれに、表面的には普通の機能に見えても「ロール」が複雑で、どの状態を基準とするかの把握が困難であったり、 設定漏れのような理由から、お客様から頂いた「ロール」や「データ」の情報と実際のWebアプリケーションの状態が異なっていることがあります。 このような場合、基準である「本来あるべき状態」を定めるのが難しくなります。
さて、突然ですが、体感をしていただくためにクイズを用意しました。
のちほど具体的なケースとして業務報告を共有するアプリケーションを例に説明をしていきますが…先行して問題です。
あなたは今、診断前に診断対象の「ロール」を確認しています。 いただいた資料によると
- メンバーはリーダーに業務報告共有の申請をする機能が診断対象である。
- 2人のリーダーと1人のメンバーのアカウントが存在する。
- メンバー1青とリーダー青は同じチームである。
このとき、 メンバー1青はリーダー橙に業務報告の共有申請が可能でしょうか？
答えは「不明」です。
もちろん、実際に機能を操作してみた結果、Webアプリケーションの画面上からは別のチームのリーダーを選択できない制限が明確にあれば、「リーダー橙への共有申請は可能でない」となります。しかし、画面上から明確に判断できない場合は「不明」として、「念のためお問い合わせをしましょう」となります。
もちろん内部でも「ふつうは同じ青チームのリーダーに申請しませんか？」とか「いやシンプルな機能だし橙でもいいんじゃないの？」とか相談をするのですが、結局それで私たちの仮説が間違っていて、脆弱性を見逃してはいけないので、「念のためお問い合わせしましょう」となります。 先にも話しましたが、この調整期間中、該当箇所の診断作業は中断となります。（もちろん、進められる別の診断対象から作業を進めるのですが、該当箇所の作業を進めることはできません。）
他にも様々な理由がありますが、「ロール」を考慮したアカウントと「データ」が準備されていると 診断作業が非常にスムーズですし、診断期間中のお問い合わせの可能性が低下します。（お客様のお手を煩わせる可能性も低下します。）
「ロール」を考慮したアカウントや「データ」を具体的なケースで考える
では改めまして、業務報告を共有するアプリケーションを例に説明をしていきます。 読者のみなさまの立場はこのアプリケーションの管理者としましょう。
この度アプリケーションが拡張され、複数企業での利用が可能となりました。 これを受けてリリース前に脆弱性診断を実施することになり、ユーザアカウントや登録データの準備を進めています。
アプリケーション利用者の「ロール」は2つで、メンバーとリーダーです。
メンバー
- 業務報告を作成する。
- 所属チームのリーダーに業務報告の公開申請をする。
リーダー
- メンバー申請された業務報告を確認し、承認をする。
業務報告は、業務に関する情報として、重要なミッションや取引先のお客様のお名前などが記載されます。 また、業務報告は"作成中”、”申請中”、”承認済”の3つの状態をもち、状態によって閲覧できる範囲が異なります。 このように、「ロール」ごとに何が出来て何ができないかを示した表を「権限マトリクス」と呼びます。
「ロール」を考慮したアカウントの確認
先ほど「本来あるべき状態」という基準を定めることができないと、診断ができないことを書きました。 ということで、なにはともあれ、「本来あるべき状態」での機能を利用できるアカウントを確認しましょう。
今回、作成と申請はメンバーのロール、承認はメンバーと所属が同じチームのリーダーのロールです。 ポイントはメンバーと所属が同じということ。 もし別チームのリーダーのアカウントが用意されていた場合、機能を利用できないので、再調整間の診断は中断してしまいます…。
以上から、メンバーと、所属チームのリーダーのロールを持つアカウントの準備を進めればよいことになります。
「データ」の確認
次に、「データ」の確認をしましょう。 アプリケーション管理者の皆様は
この度アプリケーションが拡張され、複数企業での利用が可能となりました。 これを受けてリリース前に脆弱性診断を実施することになり、ユーザアカウントや登録データの準備を進めています。
ですから、複数企業での利用を考えたユーザアカウントやデータの準備が必要です。
まずは「あるべき状態」の準備
先ほど、機能の利用に必要なロールを考え、そのアカウントを準備しました。 複数企業での利用を考えた脆弱性診断を行いたいのですから、どの企業であっても機能が利用できる状態にしてみましょう。 どの企業にもメンバーと、所属チームが同じリーダーのロールを持つアカウントを準備します。
それから「数」の準備
冒頭、「同等のロール（役割）をもつアカウントを2つ以上」と申しました。 なぜ2つ以上かといいますと、ロールは同じであっても、本来見れないはずのデータが見えてしまわないかどうかの確認のために必要なのです。
リーダはチームごとに1人なので、同じ会社の別チームのアカウントを1人追加し、 メンバーもアカウントを1人追加して、2人になるようにしましょう。
具体的には、
- 承認前の業務報告は他のメンバーからは見れないはずだが見えないだろうか？（メンバー1とメンバー２の関係）
- 申請のあった業務報告が他のリーダーから見えないだろうか？（リーダー青とリーダー橙の関係）
という確認ができるようになります。
ポイントは比較関係にあるデータは異なっているということ。
例として、メンバー1も2も「B社のI様にお会いした。」という内容の業務報告を作成中だったとしましょう。
メンバー1は、脆弱性を悪用し、2の作成中の業務報告データを閲覧しようと試行します。 …その結果表示されたのは「B社のI様にお会いした。」でした。
これでは、単に自身（メンバー1）の業務報告が表示されたのか、それとも見えてはいけないメンバー2の作成中の業務報告が表示されたのか判別がつきません。
通常利用ではなかなか無い状況ですが、基本的にテスト環境で実施される脆弱性診断では、テストデータとして投入された値がすべて"TEST"であることも考えられます。 すべて"TEST"という同じ値だった場合は、この観点の比較ができなくなるので、再調整間、該当の診断は中断してしまいます。
以上から、同じロールのアカウントは異なるデータを持たせて2つ以上、の準備を進めればよいことになります。
なお、今回の場合ですと 業務報告は社外の人間から閲覧できないかどうか（例としてA社青1とB社緑Iの関係）も確認します。
業務報告は、業務に関する情報として、重要なミッションや取引先のお客様のお名前などが記載されます。
ということで、ここまでに挙げたケースのなかで、できてしまうと一番よくないのがこの試行です。
以上から、すべてのアカウントごとに異なるデータを持っていることもポイントになります。
「ロール」を考慮したアカウントのTips
脆弱性診断の疑似攻撃の結果、用意いただいたアカウント利用ができなくなることはよくあります。 例えばアカウントロックの解除待ちであったり、アカウントが退会状態になってしまうなどです。 これらの対応の間に診断作業中断しないように、1~2アカウント程度バッファを持たせてみました。 （また、話を単純化するためにいくつか省略した「ロール」や「データ」にまつわる検査観点も確認できるようになりました。）
おわりに
今回、業務報告を作成・申請・承認するというシンプルなアプリケーションを題材に、「ロール」を考慮したアカウントや「データ」の準備について記事を書きました。 アカウントやデータの準備を依頼の裏側が伝わればうれしいです。
ちなみに今回の記事の観点の脆弱性は基本的に正常な通信を利用するもので、現時点ではツール（自動診断）での発見はできなかったり、極めて難しいのではないでしょうか。 私たち診断員が人の手で脆弱性を探します（手動診断）。
以上となります。読んでくださり、ありがとうございました！
- 脆弱性診断依頼時にアカウントやデータ類を準備してといわれる理由
- 脆弱性診断における権限関係の試行の考え方の一部
少しでも知っていただければ、うれしく思います。