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

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

新規登録して質問してみよう
ただいま回答率
85.50%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

Webサーバー

Webサーバーとは、HTTPリクエストに応じて、クライアントに情報を提供するシステムです。

Webサイト

一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

Spring

Spring Framework は、Javaプラットフォーム向けのオープンソースアプリケーションフレームワークです。 Java Platform上に、 Web ベースのアプリケーションを設計するための拡張機能が数多く用意されています。

Q&A

解決済

2回答

531閲覧

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

koronatail

総合スコア433

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

Webサーバー

Webサーバーとは、HTTPリクエストに応じて、クライアントに情報を提供するシステムです。

Webサイト

一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

Spring

Spring Framework は、Javaプラットフォーム向けのオープンソースアプリケーションフレームワークです。 Java Platform上に、 Web ベースのアプリケーションを設計するための拡張機能が数多く用意されています。

0グッド

4クリップ

投稿2018/08/20 12:40

編集2018/08/20 12:46

前提・実現したいこと

長文で失礼いたします。
現在新たに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から構築するのが初めてな上、セキュリティを徹底する必要があると上司から言われているので不安です。
知識が乏しく「それはおかしい!」「こうしたほうがいい!」ともいえないため悩んでおります。
この設計に対する問題点の指摘、こういった設計にしたほうがいいというアドバイスをいただければと思います。

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

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

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

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

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

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

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

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

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

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

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

投稿2018/08/20 14:00

hope_mucci

総合スコア4447

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

koronatail

2018/08/20 14:16

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

2018/08/20 14:35

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

0

ベストアンサー

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

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

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

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

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

投稿2018/08/20 13:35

ockeghem

総合スコア11701

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

koronatail

2018/08/20 13:47

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

2018/08/20 14:02

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

2018/08/20 14:20

なるほどやり取りすること自体が分離という観点から外れているということですね。 機能的に(2)のアプリが個人情報を利用するのは避けられないのでシンプルにするためにも「この設計ではそもそも分離できていない」という観点で設計を見直す方向に持っていけるよう相談してみたいと思います。 お二方の回答とても参考になりました。 ありがとうございました。 (回答が先だったockeghem様をベストアンサーにさせていただきました)
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問