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

Question

前提・実現したいこと

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

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

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

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

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

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

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

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

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

お聞きしたいこと

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

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

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

Answer 1

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

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

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

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

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

---

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

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

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

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

Comments

[koronatail]

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

[hope_mucci]

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

Answer 2

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

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

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

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

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

Comments

[koronatail]

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

[ockeghem]

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

[koronatail]

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

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