0
4
イントラ端末上でWeb開発することのリスクについて
社内向けWebアプリ開発を行っていますが、セキュリティリスクを指摘され、対応を模索しています。
背景、状況
団体組織の情報システム子会社で開発業務に従事しているものです。
5年程前にUターンで中途入社しましたが、ACCESS、COBOL資産ばかりで、作業効率が低く、若手職員のモティベーションも低かったため、有志で徐々にレガシーシステムのWebアプリ化を行っています。
(DRF+Vue.js+Docker、社内オンプレLinuxサーバーで稼働)
利用形態
社内ネットワークは BEW で構築されています。開発はWeb閲覧が可能な社内のイントラ端末上で行っています。必要なパッケージは、プロキシ設定を行って npm、pip等のパッケージマネージャにより行っています。
アプリケーション利用者は会社・団体職員のみで、社外に公開することはありません。
課題
当初、Webアプリ開発についての理解が得づらかったため、半ば見切り発車・既成事実化する形で進めてきています。(手伝ってくれる若手の反応は良く、ユーザー部門からも利便性が向上して高評価なのですが)
金融資産や与信に関する情報など、機微情報を扱うシステムについてもWeb化を進めていますが、Web化に難色を示す年配者からはインターネットに接続可能な端末上でWeb開発をすることの危険性を指摘しています。
漠然とした無学な質問で大変恐縮なのですが、一般のWeb開発企業等ではどのようなセキュリティ対策を行った上でWebアプリ開発をされているのでしょうか?
もちろん規模にもよるのでしょうが、例えば、オフライン開発環境を設け、自前でプライベートリポジトリを運用されていたりするのでしょうか?
前職でも案件でWebアプリ開発をしていましたが、特にイントラ端末上でパッケージをダウンロードしたりすることに制約はありませんでした。
(会社の規模が小さく、セキュリティ意識が自他ともに低かったのかもしれませんが...)
今後さらにWeb化は進めていくことになりそうですが、社内調整を円滑に行うために、事例などあればご教示頂けましたら幸いです。
よろしくお願いいたします。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答13件
#1
総合スコア684
投稿2023/03/31 01:57
セキュリティリスクを指摘され
具体的にどんな点を指摘されたのでしょうか?
その内容次第で議論すべき内容が変わってくるように思います。
またセキュリティ指摘が入っている最中、
このようなオープンな場にクライアント名を出すべきではありませんよ。
#2
総合スコア684
投稿2023/03/31 02:24
一般のWeb開発企業等ではどのようなセキュリティ対策を行った上でWebアプリ開発をされているのでしょうか?
一般的にはアクセス制限をかけるだけです。
普段お使いのどんなWebサービスもそうなっているはずです。
アクセス制限の掛け方ですが、
それはクライアントの環境次第です。
例えば一番硬いのはIP制限ですが、
それをやるには利用者側が固定IP環境である必要があります。
VPN環境で利用が可能ならそれでも良いと思います。
逆に軽い制限としては、
古典的なBasic認証ですが、総当たり対策等は必要です。
一部の大手プロバイダでも採用しています。
もしくはアプリケーション自体に脆弱性がない前提ですが、
一般的なWebサイト同様にID/PASSのユーザー認証をつけることですね。
組み合わせで、
IP制限+利用ユーザー個々のID/PASSの認証が良いと思います。
そもそもインターネット上への設置自体が指摘されるのであれば、
設置自体はイントラで、利用ユーザーにはVPNでイントラに繋いで貰えばいいと思います。
イントラ環境の整備など、それなりに大変で、
クラウドではないので可用性維持など、保守運用も大変だとは思いますが。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#3
#1
ご指摘有難うございます(組織名は修正いたしました)。また、漠然とした説明で申し訳ありません。
指摘する人は、インターネットに接続している端末で、機微情報を含むDBに接続していると、左記情報の流出が起きるのではないかということを最も懸念しているようです。
イントラ端末上にデータは保持しない、と説明していますが、納得できないようです。
現状、指摘者に一応の回答をするために以下のものを提案しようかと考えているのですが...
①開発時はジャミングされたDBに接続する、あるいは機微情報を含むDBに接続するときはイントラ端末のインターネット接続を閉じる
(アプリ開発上でWEB閲覧可能なイントラ端末からDBにアクセスすることが危険なら、ファイルサーバその他リソースへの既存アクセスも同様では?という点で、余り意味がない気もしています)
②主に利用するSQL Serverにて「厳密な接続暗号化」設定を行う
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#4
総合スコア684
投稿2023/03/31 02:41
順番が前後してしまったと思いますが、
#2は修正後の内容に対しての回答となります。
指摘する人は、インターネットに接続している端末で、機微情報を含むDBに接続していると、左記情報の流出を最も懸念しているようです。
昨今のセキュリティ事故などのニュースだけ見ている非技術者であれば、
そのように指摘をするのは仕方ないかと思います。
故に、あまり技術的なアプローチは望めません。
がしかし、そんなことを指摘する人でさえ、
GAFAMをはじめとしたWebサービスに個人情報を預けているはずですよ。
普段の業務でもASPサービスは使っているはずです。例えばメール。
それを理解した上での先方の指摘であれば、大手サービスとの差分は信頼ですよね。
失礼ですが、あなたの会社の信頼や実績、スキルがないと思われてしまっている故の指摘であるとも思えます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#5
総合スコア323
投稿2023/03/31 03:40
インターネットに接続している端末で、機微情報を含むDBに接続していると、
左記情報の流出が起きるのではないか
これ「(有効数字無限大で)100パーセント起こらない」って誰も言えませんよね。
このテの「100パーセント安全を保証しろ」は雑に言うと「俺は責任取りたくない」
という主張なので、技術の話をしても無駄です。
(まれに社会的ナンタラカンタラもあるかもしれませんが。)
#4 で指摘されているように時間をかけて信頼を勝ち取る(お前らが事故ったら
俺が責任取ってやるよと言ってもらう)か、「事故が発生した時の責任と損害賠償
その他諸々は一切自分が受けます」って契約にするしかないのでは。
あと、
漠然とした無学な
が謙遜なのか事実なのかわかりませんが、少なくともこんなこと言ってる間は
相手に信頼されないと思いますので、俺様が世界一…は無理でも、都道府県一
やぞ文句あるか!くらい言えるようになるといいですね。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#6

退会済みユーザー
総合スコア0
投稿2023/03/31 04:00
「安全なウェブサイトの作り方」とかのお話ではなく、
(運用時ではなく)開発時における環境のお話ですね。
一般のWeb開発企業等ではどのようなセキュリティ対策を行った上でWebアプリ開発をされているのでしょうか?
例えば、オフライン開発環境を設け、自前でプライベートリポジトリを運用されていたりするのでしょうか?
すみません、
何か解決策になるようなことではないのですが、
現状の把握になればと思い書いてみます。
”一般の”Web開発企業等に当てはまらないかもしれませんが、
金融機関などでは
「オフライン開発環境を設け、自前でプライベートリポジトリを運用されていたりする」
ようなところもあると思います。
質問者様の業務を正しく把握できていないかもしれませんが、
「COBOL資産」「金融資産や与信に関する情報」などの言葉もあり、
どちらかというと、金融機関に近い業務なのかなという印象でした。
金融機関などでは
インターネットに繋がらない開発用のPCとインターネットに繋がるシンクライアントの2台が割り当てられたり、
インターネットに繋がらない開発用のPCだけしか割り当てられず、しかもデスクへの携帯電話の持ち込みすら不可能だったり、
そういうところもあったりするみたいです。
(最近や今後がどうなのかわからないところもありますが・・)
最近もそうなのか気になって、「金融機関 システム開発 インターネットが使えない」で検索してみました。
2020,2018(2022)の記事もヒットしましたので、まだそういうところはあるのではないかと思いました。
(でも、2020年あたりから一気にリモートワーク化が進みましたので、ここから状況も変わったかもしれないですね)
https://note.com/gevanni/n/nec93a89e05aa
https://makicebu.com/it-job-finance
(ネガティブな記事ですが・・)
ここまで書いてきて一つ気になりました。
今までのAccessやCOBOLはイントラネット環境で開発しているのですよね?
そうだとすると、
「インターネットに接続している端末で、機微情報を含むDBに接続していると、左記情報の流出が起きるのではないか」
は、今までの開発においても懸念されるように思うのですが、
そういうのはないのでしょうか?
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#7
#6
ご回答有難うございます。
お気づきの通り、金融関連の業務も行っています。
私とは別の部署になりますが、ACCESS や COBOL 開発を行う部署では、オフライン環境での開発となっています。
私の部署でも当初 ACCESS しかなかったのですが、Webアプリ開発をする関係上、開発端末ではなく、(各種リポジトリと疎通可能な) Web閲覧可能なイントラ端末上で作業をしているという状況です。
賛否あると思いますが、社内議論の熟成を待っていると「ダメ!」から一歩も進まないので、Web閲覧可能な端末上での開発作業を既成事実的に行い、アプリも複数本番リリースしています(オンプレの外部非公開Webアプリ)。
ご提示の事例に準じる形で、本番DBにアクセスするための環境はオフラインにするなども、上層部の指摘に対応するための一案かなと思っています。
(開発環境では機微情報をジャミングしたDBに接続して作業)
(本番データを使用した解析作業はオフラインの端末で行う、アプリをsyncする時だけその端末はネット接続する)
組織風土が非常に守旧的で、普通の現場では問題にならないような質問をしているのも承知なのですが、COBOLやACCESSしか触ったことがない人々のしてくる指摘に対して、どう対応しようかと頭を悩ませたうえでのこちらでのご質問でした...
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#8

退会済みユーザー
総合スコア0
投稿2023/03/31 05:32
ご返信ありがとうございます。
私とは別の部署になりますが、ACCESS や COBOL 開発を行う部署では、オフライン環境での開発となっています。
すでにそういう環境があってのことなのですね。
そういうルールが決まっているのだとしたら、それを変えるのは大変なことかもしれないですね。
賛否あることを承知で白状すると、社内議論の熟成を待っていると「ダメ!」から一歩も進まないので、Web閲覧可能な端末上での開発作業を既成事実的に行い、アプリも複数本番リリースしています。
ルールを守っていないことになってしまいますので、、
無条件に賛成することはできないかもしれませんが、、
過去、何かを変えてきた人は、こんな感じなのかなと思ったりもします。
やりやすい開発環境になるように応援したいです。
金融関係の業務でオフライン環境で開発するというルールがある場合、
「一般のWeb開発企業等ではどのようなセキュリティ対策を行った上でWebアプリ開発をされているのでしょうか?」
のような一般のWeb開発企業等がOKだからという理由だけでは
それを変えるのは難しそうという気がしました。
システム上重要な銀行入門-「大きすぎて潰せない(TBTF)」問題について- : 財務省
企業の規模が大きいか小さいかは置いておいてしまいますが、
金融機関の業務は
「銀行の破綻が他の銀行の破綻をもたらすなど、連鎖的な影響を与えうることから、」(財務省のリンク先から引用)
一般のWeb開発企業等とは違う考え方(経営的な判断・決定)をされていても仕方ないのかなとも思ったりします。
(でも、常識は時代と共に変わったりするのかなとも思ったりします)
ちょっと話がずれてしまうかもしれませんが、
コロナ禍ではオフライン環境の開発はどのようになりました?
リモートワークにはならなかったのでしょうか?
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#9
総合スコア86207
投稿2023/03/31 05:35
編集2023/03/31 06:16A案:
データをきちんと管理して、開発端末上には絶対に「漏れてはいけないデータ」は置くことが出来ないようにする。
ただ、これでも事故によるソースコードの流出はあり得ます。外部向けProxyサーバーでのフィルタリングを細かくやることである程度は軽減できますが。
また、ルールや仕組みをきちんと作っても、USBメモリ経由などで本番データを開発端末にコピーする人がでないとも限らず(尼崎市事件など)、そこも何らかの仕組みを作る必要があります。本番アクセスは施錠されてカメラで記録された部屋で行うとかUSB書き込み不可など。尼崎市事件のレポートで「今後はこうします」という部分が参考になるかと思います。
B案:
本番環境テスト以外のテストでも本番データを使う習慣のある組織でA案をゼロからやるのは大変そうです。
お書きのように、必要なパッケージのリポジトリを閉じた環境内に作る方が、A案をきっちりやるより楽な気がします。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#10
#8
有難うございます。
うがっているのかもしれませんが、Web化したくない雰囲気の方は年配が多く...
私見ですが自分達が作ったレガシーがリプレースされること・管理できないシステムが増えること自体に感情的な抵抗を感じているのではとも思っています。
頂いたご意見を元に、受容頂けるよう対策を考えていきたいと思います。
コロナ対応では、在宅・出社をグループ分けするスプリット勤務になっていました。
なので、在宅勤務組はリモートデスクトップサービスのツールを使い、在宅勤務をしていました。
ただし、金融関連のグループだけは全員出社で、その代わり出社時にフロアを分ける形での対応となっていました。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#12

退会済みユーザー
総合スコア0
投稿2023/03/31 15:20
ご返信ありがとうございます。
何度も書き込みしてしまってすみません。
(?をつけて書き込んで、返信をもらったのに、それに返信しないのは失礼かと思いまして、)
(でも、これで区切りをつけますので)
感情的な抵抗を感じているのではとも思っています。
そうなのですね。
確かに、人間だからそういうこともありそうですね。
ただし、金融関連のグループだけは全員出社で、
ちょっとずつ質問者様の状況を把握できてきました。
金融関連のグループはやっぱり厳しそうで、
質問者様のグループはそれよりは厳しくはなく、
そのあたりは理解・配慮してもらえている状況なのですね。
金融関連ではない業務の環境を変えていくのは、
とっかかりとしては良さそうですね。
私がここまで書いてきた金融機関のイメージは、
支店・窓口があるような銀行のイメージだったのですが、
最近はネット銀行もありますよね。
金融関係でもネット銀行はちょっと考え方が違うのかな?とも思ったりします。
そういう現場で働いている人の意見とか聞いてみたいですね。
ちょっと下書きしてから、休憩したりしていて、思い出したのですが、
少し前に本を読みまして、その中に記載されていた小話についてです。
エレベーターが遅いという苦情に対処したお話だったのですが、
その対処というのが、エレベーター自体を改善するとかじゃなくて、
エレベーターの近くに鏡を設置したら苦情はなくなった、
というようなお話だったと思います。
エレベーターが遅いこと自体は根本の問題ではなかったらしく、
人間が遅いと感じることが問題だったみたいです。
(鏡で姿をチェックしていると待っている時間が気にならないということだった気がします)
(メモしていなくて、うろ覚えなので間違っているかもしれません・・)
「感情的な抵抗を感じているのでは」
と記載されていましたので、
(セキュリティ自体のことを完全に無視してとは言いませんが、)
感情的な面からのアプローチがあっても良いのかもしれないと思いました。
根本の問題が何か理解するところから、
相手をちゃんと理解するところから、
と思いますので、頑張ってください。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。