質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.21%

【設計?】セキュリティの観点から個人情報にアクセスするwarとそれ以外の機能をもったwarをわけるという考え方

解決済

回答 2

投稿 編集

  • 評価
  • クリップ 4
  • VIEW 722

koronatail

score 420

 前提・実現したいこと

長文で失礼いたします。
現在新たにWEBシステムを立ち上げようとしています。
機能としては、利用者がログインして、自分のアカウントに関連づくデータを表やグラフ形式で表示するといったものです。
また前提として、このシステムでは氏名などの個人情報とパスワードを非常に機微なものとして扱うものと位置づけています。

要件定義を行っている中で、ある社員の方が「個人情報の入っているデータベースにアクセスするアプリケーションは分けたほうが、セキュリティ的に安全なのでは?」という意見を上げました。
セキュリティの専門家のような方もいないので、なんとなーくな雰囲気で「まぁ確かに」という空気になって話がそのまま進んでいきました。

上記の話を聞いた上で、私が細かい設計を考え始めたところ、「個人情報にアクセスするアプリケーションを分ける」という話をWEBシステムに落とすと「個人情報にアクセスするためだけのwarが必要になるのかな?」と考えました。

その話を踏まえたうえでサーバーとアプリケーションの構成を以下のように書き起こしました。

---------------------------------
WEBサーバー(Apache httpd)
┗アプリケーションサーバー(Tomcat)
┣(1)ログイン・個人情報アクセス.war
┗(2)その他の機能(データ表示ページなどを表示する).war

データベース(データベースの構成は諸事情で大きく変更することができません。
┣(A)ログイン情報・個人情報を格納するデータベース
┗(B)その他の情報を格納するデータベース
---------------------------------

(2)のwarで氏名などの個人情報が必要になった場合、(1)がDBから個人情報を取得して(2)に渡すという想定です。
渡す方法としては、(1)にRest APIのような機能を持たせて(2)からリクエストを送って取得するか、(1)でセッションに個人情報を格納して(2)から参照する方法を考えました。

この内容で周りに確認したところ特に否定的な意見も無かったのでこのまま話が進みました。

しかし、いざ自分で製作を始めると(自分で作っておいてなんですが)この設計に意味があるのかが疑問になりました。

 お聞きしたいこと

①.そもそも「個人情報の入っているデータベースにアクセスするアプリケーションは分けたほうが、セキュリティ的に安全なのでは?」という意見は正しいのでしょうか。
同じサーバーで動いているならこのサーバーがハッキングされた時点で終わりですしあまり意味が無いような気もしますがどうなのでしょうか。
単一のwarファイルから個人情報にアクセスしてそれを表示するよりも安心といえるのでしょうか。
②.①の意見が正しいとして、私の構成は正しいのでしょうか
(A)のように個人情報とログイン情報が同じデータベースに格納されている関係上、個人情報を利用して画面に表示するwarとログイン処理を行うwar分ける必要性があると考えています。
そのため、(1)ではJWTを用いた認証を行い、(2)にアクセスされた場合クライアントがクッキーに持っているJWTを検証してログイン済みかどうかを確認し、ログイン済みであると確認できれば(2)から(1)の個人情報取得用APIに対して同じJWTを含んだリクエストを送って個人情報を取得しようと考えております。
しかし、個人情報を取得するのにいちいちAPIを叩くのは煩雑ですし、(1)個人情報取得用の口を作るのもセキュリティ的にどうなのという気もします。

実際にインターネットに公開されるWEBシステムを0から構築するのが初めてな上、セキュリティを徹底する必要があると上司から言われているので不安です。
知識が乏しく「それはおかしい!」「こうしたほうがいい!」ともいえないため悩んでおります。
この設計に対する問題点の指摘、こういった設計にしたほうがいいというアドバイスをいただければと思います。

なにとぞよろしくお願いします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 2

checkベストアンサー

+1

ちゃんとした検証をするには情報が不足しているので、あくまで印象論として回答します。
結論としては、「安全になるとは言えない」と思います。

一般論として、個人情報を扱うアプリケーションと個人情報を扱わないアプリケーションを分離することは、セキュリティ上は有利に働きます。しかし、ご質問のアプリケーションの場合、この分離はできていないようにお見受けましす。

であれば、できるだけアプリケーションのアーキテクチャをシンプルに保ち、かつ、一般的なベストプラクティスに従う方が、安全なアプリケーションを楽に開発できると思います。
質問として提示いただいたアーキテクチャはやや複雑のように感じました。複雑さは脆弱性の原因になりますし、独自のアーキテクチャは、「教科書に載っていない脆弱性」の原因になります。

したがって、アプリケーションを分離せずに、シンプルさを保った方が賢明であると考えます。

複雑なアプリケーションが本当に安全かどうかは、セキュリティの専門家にみてもらうしかないと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/08/20 22:47

    >ockeghem様
    回答のほうありがとうございます。重ねての質問になってしまうのですが、
    「一般論として、個人情報を扱うアプリケーションと個人情報を扱わないアプリケーションを分離することは、セキュリティ上は有利に働きます。」
    これを実装しようと思ったとき、個人情報を扱うアプリケーションと扱わないアプリケーション間での個人情報のやり取りとして、考えられる方法はどんな方法があるものなのでしょうか。(WEBシステムに限らずクライアントサーバーシステムでも)
    開発期間が短いこともあり、なるべくシンプルにしたいのですが自分からこれを提案してしまったので理由を説明しないとなかなか引っ込めづらくて・・・

    キャンセル

  • 2018/08/20 23:02

    > これを実装しようと思ったとき、個人情報を扱うアプリケーションと扱わないアプリケーション間での個人情報のやり取りとして、考えられる方法はどんな方法があるものなのでしょうか。(WEBシステムに限らずクライアントサーバーシステムでも)
    個人情報をやり取りしているということは、その時点で分離できていないことになります。私が言っている「個人情報を扱わないアプリケーション」は、文字通り個人情報を一切扱わないことを指します。

    キャンセル

  • 2018/08/20 23:20

    なるほどやり取りすること自体が分離という観点から外れているということですね。
    機能的に(2)のアプリが個人情報を利用するのは避けられないのでシンプルにするためにも「この設計ではそもそも分離できていない」という観点で設計を見直す方向に持っていけるよう相談してみたいと思います。

    お二方の回答とても参考になりました。
    ありがとうございました。
    (回答が先だったockeghem様をベストアンサーにさせていただきました)

    キャンセル

+1

うーん、文面からではきちんとしたリスクアセスメントを実施している感じがしないんのですが…
そんな「何となく」な雰囲気で決めてしまっていませんか?

リスクアセスメントの詳細はISMSを勉強してもらうとして、簡単に書くと

  • リスク特定(どんなリスクがあるか)
  • リスク分析(どのくらいのインパクトがあるか)
  • リスク評価(それが受容できるかどうか)

という流れになります。
受容ができない、となるとそのリスクに対応する必要があります。
「warやDBを分ける」のはリスク対応に相当しますが、その前段でどのようなリスクアセスメントを行ったかが重要になります。

  • 具体的にどのような脅威が発生するか、検討しましたか?
  • その脅威が発生したらどのくらいのインパクトがあるか(個人情報漏洩だと対応コスト、損害賠償などが考えられます)
  • それが発生した場合、会社は経営上耐えられますか?

さて、リスク対応内容の話に移ります。
どれだけwarを分けても、システムを利用する側としては全部まとめて1つなわけなので、セキュアな観点での機能分離はこの構成からはできていないように思います。
REST APIは外部に公開しますか?内部だけで使用(アプリ2からしかアクセスできないようにする)ですか? 前者ならばそれだけで大きなセキュリティリスクとなるでしょう。

データベースを分けることに関しても、AとBのセキュリティレベルが異なるのであれば(当然AのほうがBより強固である前提)一定の意味があるとは思いますが、同じサーバーに乗っていたり、Oracle的な表現になりますがBからAにDBLINKを張っていたりすると分離させた意味がありません。
(API作るくらいだからAとBの直接的なやり取りは皆無と思いますけど)

最終的にはリスクインパクトと対応コストの見合いなので、組織内でコミットメントがあればプロジェクトとしてはそれでよいのですが、適切な検討を実施しているのかな?と疑問に思います。
プロジェクトメンバーで十分なコンセンサスがないと、いざコトが起こった時にものすごく揉めます。

文面を見ている限り、どのようなプロセスがあったにせよ対応内容はコミットされているようなので、あなたは粛々と決定に従い対応策を考え、レビューを受け、実装していくべきでしょう。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/08/20 23:16

    >hope_mucci様
    回答のほうありがとうございます。
    >そんな「何となく」な雰囲気で決めてしまっていませんか?
    返す言葉もありません・・・決める人がいないというか雰囲気で決まったセキュリティ要件に対して大した知識もない私が行き当たりばったりで対応してるのでこんなことになっているのですが・・・。
    REST APIはIPアドレス当たりで制限をかけてアプリ2からのリクエストだけを受け付ける形にしようかと思っています。
    一応仕様の確認はしてもらってはいるのですがプロジェクトメンバー内にセキュリティについてはっきり評価できる方がいないので悩んでおります。
    ひとまず「分離できれば安全だけど、考え直したところシステムを利用する側が1つにまとまっているので分離できていない形になってしまっている」という方向で検討しなおす方向に持っていけないか相談して見ようかと思います。

    キャンセル

  • 2018/08/20 23:35

    結局個人情報はアプリ1を通過するのでアプリレベルでは個人情報を分離できていません。
    2つのアプリを別々の外注に出すとか、そういう状況ならある程度の意味はありますがおそらくそういう状況ではないと思いますし。
    「結局アプリ1は個人情報を扱うのでアプリを分割してもリスクは同じ」という方向で相談してみたらどうでしょうか、とお伝えしておきます。
    また、余談ですが「脆弱性診断」というサービスを実施している会社があります。システムテストができる段階で脆弱性診断を受けてリスクを洗い出してもらうのも1つの方法です。サービスインする前にリスクがわかりますし、契約によっては対策方法も教えてくれるでしょう。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.21%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる
  • トップ
  • Javaに関する質問
  • 【設計?】セキュリティの観点から個人情報にアクセスするwarとそれ以外の機能をもったwarをわけるという考え方