する質問をすることでしか得られない、回答やアドバイスがある。420前提・実現したいこと長文で失礼いたします。現在新たにWEBシステムを立ち上げようとしています。機能としては、利用者がログインして、自分のアカウントに関連づくデータを表やグラフ形式で表示するといったものです。前提として、このシステムでは氏名などの個人情報とパスワードを非常に機微なものとして扱うものと位置づけています。要件定義を行っている中で、ある社員の方が「個人情報の入っているデータベースにアクセスするアプリケーションは分けたほうが、セキュリティ的に安全なのでは?」という意見を上げました。セキュリティの専門家のような方もいないので、なんとなーくな雰囲気で「まぁ確かに」という空気になって話がそのまま進んでいきました。上記の話を聞いた上で、私が細かい設計を考え始めたところ、「個人情報にアクセスするアプリケーションを分ける」という話をWEBシステムに落とすと「個人情報にアクセスするためだけのwarが必要になるのかな?」と考えました。その話を踏まえたうえでサーバーとアプリケーションの構成を以下のように書き起こしました。httpd)┗アプリケーションサーバー(Tomcat)┣(1)ログイン・個人情報アクセス.war┗(2)その他の機能(データ表示ページなどを表示する).warデータベース(データベースの構成は諸事情で大きく変更することができません。)┣(A)ログイン情報・個人情報を格納するデータベース┗(B)その他の情報を格納するデータベース---------------------------------(2)のwarで氏名などの個人情報が必要になった場合、(1)がDBから個人情報を取得して(2)に渡すという想定です。APIのような機能を持たせて(2)からリクエストを送って取得するか、(1)でセッションに個人情報を格納して(2)から参照する方法を考えました。この内容で周りに確認したところ特に否定的な意見も無かったのでこのまま話が進みました。いざ自分で製作を始めると(自分で作っておいてなんですが)この設計に意味があるのかが疑問になりました。お聞きしたいこと1.そもそも「個人情報の入っているデータベースにアクセスするアプリケーションは分けたほうが、セキュリティ的に安全なのでは?」という意見は正しいのでしょうか。同じサーバーで動いているならこのサーバーがハッキングされた時点で終わりですしあまり意味が無いような気もしますがどうなのでしょうか。単一のwarファイルから個人情報にアクセスしてそれを表示するよりも安心といえるのでしょうか。2.1の意見が正しいとして、私の構成は正しいのでしょうか(A)のように個人情報とログイン情報が同じデータベースに格納されている関係上、個人情報を利用して画面に表示するwarとログイン処理を行うwar分ける必要性があると考えています。そのため、(1)ではJWTを用いた認証を行い、(2)にアクセスされた場合クライアントがクッキーに持っているJWTを検証してログイン済みかどうかを確認し、ログイン済みであると確認できれば(2)から(1)の個人情報取得用APIに対して同じJWTを含んだリクエストを送って個人情報を取得しようと考えております。個人情報を取得するのにいちいちAPIを叩くのは煩雑ですし、(1)個人情報取得用の口を作るのもセキュリティ的にどうなのという気もします。実際にインターネットに公開されるWEBシステムを0から構築するのが初めてな上、セキュリティを徹底する必要があると上司から言われているので不安です。知識が乏しく「それはおかしい!」「こうしたほうがいい!」ともいえないため悩んでおります。この設計に対する問題点の指摘、こういった設計にしたほうがいいというアドバイスをいただければと思います。attachmentクリップ4気になる質問をクリップするクリップした質問は、後からいつでもマイページで確認できます。クリップした質問に回答があった際、通知やメールを受け取ることができます。自分も答えを知りたい質問者以外のユーザにも役立つ評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。質問の評価を上げたことを取り消します低評価-評価を下げられる数の上限に達しました評価を下げることができません1日5回まで評価を下げられます1日に1ユーザに対して2回まで評価を下げられます質問の評価を下げるteratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。コメントをしてください。送信する質問の評価を下げる機能の利用条件この機能を利用するためには、以下の事項を行う必要があります。件sort評価が高い順sort新着順sort古い順linkcheckベストアンサー+1ちゃんとした検証をするには情報が不足しているので、あくまで印象論として回答します。結論としては、「安全になるとは言えない」と思います。一般論として、個人情報を扱うアプリケーションと個人情報を扱わないアプリケーションを分離することは、セキュリティ上は有利に働きます。ご質問のアプリケーションの場合、この分離はできていないようにお見受けましす。あれば、できるだけアプリケーションのアーキテクチャをシンプルに保ち、かつ、一般的なベストプラクティスに従う方が、安全なアプリケーションを楽に開発できると思います。質問として提示いただいたアーキテクチャはやや複雑のように感じました。複雑さは脆弱性の原因になりますし、独自のアーキテクチャは、「教科書に載っていない脆弱性」の原因になります。したがって、アプリケーションを分離せずに、シンプルさを保った方が賢明であると考えます。複雑なアプリケーションが本当に安全かどうかは、セキュリティの専門家にみてもらうしかないと思います。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。回答のほうありがとうございます。「一般論として、個人情報を扱うアプリケーションと個人情報を扱わないアプリケーションを分離することは、セキュリティ上は有利に働きます。」これを実装しようと思ったとき、個人情報を扱うアプリケーションと扱わないアプリケーション間での個人情報のやり取りとして、考えられる方法はどんな方法があるものなのでしょうか。回答のほうありがとうございます。「一般論として、個人情報を扱うアプリケーションと個人情報を扱わないアプリケーションを分離することは、セキュリティ上は有利に働きます。これを実装しようと思ったとき、個人情報を扱うアプリケーションと扱わないアプリケーション間での個人情報のやり取りとして、考えられる方法はどんな方法があるものなのでしょうか。これを実装しようと思ったとき、個人情報を扱うアプリケーションと扱わないアプリケーション間での個人情報のやり取りとして、考えられる方法はどんな方法があるものなのでしょうか。(WEBシステムに限らずクライアントサーバーシステムでも)個人情報をやり取りしているということは、その時点で分離できていないことになります。私が言っている「個人情報を扱わないアプリケーション」は、文字通り個人情報を一切扱わないことを指します。これを実装しようと思ったとき、個人情報を扱うアプリケーションと扱わないアプリケーション間での個人情報のやり取りとして、考えられる方法はどんな方法があるものなのでしょうか。個人情報をやり取りしているということは、その時点で分離できていないことになります。私が言っている「個人情報を扱わないアプリケーション」は、文字通り個人情報を一切扱わないことを指します。23:20なるほどやり取りすること自体が分離という観点から外れているということですね。機能的に(2)のアプリが個人情報を利用するのは避けられないのでシンプルにするためにも「この設計ではそもそも分離できていない」という観点で設計を見直す方向に持っていけるよう相談してみたいと思います。お二方の回答とても参考になりました。ありがとうございました。(回答が先だったockeghem様をベストアンサーにさせていただきました)なるほどやり取りすること自体が分離という観点から外れているということですね。機能的に(2)のアプリが個人情報を利用するのは避けられないのでシンプルにするためにも「この設計ではそもそも分離できていない」という観点で設計を見直す方向に持っていけるよう相談してみたいと思います。お二方の回答とても参考になりました。ありがとうございました。(回答が先だったockeghem様をベストアンサーにさせていただきました)キャンセル完了するlink+1うーん、文面からではきちんとしたリスクアセスメントを実施している感じがしないんのですが...そんな「何となく」な雰囲気で決めてしまっていませんか?リスクアセスメントの詳細はISMSを勉強してもらうとして、簡単に書くとリスク特定(どんなリスクがあるか)リスク分析(どのくらいのインパクトがあるか)リスク評価(それが受容できるかどうか)という流れになります。受容ができない、となるとそのリスクに対応する必要があります。「warやDBを分ける」のはリスク対応に相当しますが、その前段でどのようなリスクアセスメントを行ったかが重要になります。具体的にどのような脅威が発生するか、検討しましたか?その脅威が発生したらどのくらいのインパクトがあるか(個人情報漏洩だと対応コスト、損害賠償などが考えられます)それが発生した場合、会社は経営上耐えられますか?さて、リスク対応内容の話に移ります。どれだけwarを分けても、システムを利用する側としては全部まとめて1つなわけなので、セキュアな観点での機能分離はこの構成からはできていないように思います。前者ならばそれだけで大きなセキュリティリスクとなるでしょう。データベースを分けることに関しても、AとBのセキュリティレベルが異なるのであれば(当然AのほうがBより強固である前提)一定の意味があるとは思いますが、同じサーバーに乗っていたり、Oracle的な表現になりますがBからAにDBLINKを張っていたりすると分離させた意味がありません。(API作るくらいだからAとBの直接的なやり取りは皆無と思いますけど)最終的にはリスクインパクトと対応コストの見合いなので、組織内でコミットメントがあればプロジェクトとしてはそれでよいのですが、適切な検討を実施しているのかな?と疑問に思います。プロジェクトメンバーで十分なコンセンサスがないと、いざコトが起こった時にものすごく揉めます。文面を見ている限り、どのようなプロセスがあったにせよ対応内容はコミットされているようなので、あなたは粛々と決定に従い対応策を考え、レビューを受け、実装していくべきでしょう。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。回答のほうありがとうございます。>そんな「何となく」な雰囲気で決めてしまっていませんか?返す言葉もありません・・・決める人がいないというか雰囲気で決まったセキュリティ要件に対して大した知識もない私が行き当たりばったりで対応してるのでこんなことになっているのですが・・・。APIはIPアドレス当たりで制限をかけてアプリ2からのリクエストだけを受け付ける形にしようかと思っています。一応仕様の確認はしてもらってはいるのですがプロジェクトメンバー内にセキュリティについてはっきり評価できる方がいないので悩んでおります。「分離できれば安全だけど、考え直したところシステムを利用する側が1つにまとまっているので分離できていない形になってしまっている」という方向で検討しなおす方向に持っていけないか相談して見ようかと思います。回答のほうありがとうございます。返す言葉もありません・・・決める人がいないというか雰囲気で決まったセキュリティ要件に対して大した知識もない私が行き当たりばったりで対応してるのでこんなことになっているのですが・・・。APIはIPアドレス当たりで制限をかけてアプリ2からのリクエストだけを受け付ける形にしようかと思っています。一応仕様の確認はしてもらってはいるのですがプロジェクトメンバー内にセキュリティについてはっきり評価できる方がいないので悩んでおります。「分離できれば安全だけど、考え直したところシステムを利用する側が1つにまとまっているので分離できていない形になってしまっている」という方向で検討しなおす方向に持っていけないか相談して見ようかと思います。23:35結局個人情報はアプリ1を通過するのでアプリレベルでは個人情報を分離できていません。2つのアプリを別々の外注に出すとか、そういう状況ならある程度の意味はありますがおそらくそういう状況ではないと思いますし。「結局アプリ1は個人情報を扱うのでアプリを分割してもリスクは同じ」という方向で相談してみたらどうでしょうか、とお伝えしておきます。余談ですが「脆弱性診断」というサービスを実施している会社があります。システムテストができる段階で脆弱性診断を受けてリスクを洗い出してもらうのも1つの方法です。サービスインする前にリスクがわかりますし、契約によっては対策方法も教えてくれるでしょう。結局個人情報はアプリ1を通過するのでアプリレベルでは個人情報を分離できていません。2つのアプリを別々の外注に出すとか、そういう状況ならある程度の意味はありますがおそらくそういう状況ではないと思いますし。「結局アプリ1は個人情報を扱うのでアプリを分割してもリスクは同じ」という方向で相談してみたらどうでしょうか、とお伝えしておきます。余談ですが「脆弱性診断」というサービスを実施している会社があります。システムテストができる段階で脆弱性診断を受けてリスクを洗い出してもらうのも1つの方法です。サービスインする前にリスクがわかりますし、契約によっては対策方法も教えてくれるでしょう。頂いたご意見への回答は行っておりません。