アカウント名:
パスワード:
ウイルスに遠隔操作されても個人情報にアクセスできないような気がするのですが。。。
のようですね。
ウイルスに遠隔監視されてる端末上で、職員が個人情報へのアクセスを行うと……。
監視された状態で個人情報にアクセスすれば遠隔地でその情報を見れるのはわかるんですが、790万人分にアクセスって相当な量ですので不思議に思って。
遠隔操作もあったにしても790万件のアクセスってなかなかできないですよ。
アクセスして得た個人情報それ自体を見ることが重要なのではなく、その直前に認証してアクセス権限を取得する手続きを見ることが重要なのです。
データベースサーバに自由自在にアクセスできる権限のあるPCというのを外部と接触するネットワークから完全に隔離しておけば、漏洩はしなかったはず。
完全隔離と業務の効率化とを両立させるような仕掛けはありえないのでしょうか?
自由にアクセスできる端末と、制限付きアクセスを認められた端末で運用する事は比較的容易なはずです。更に、メーラーをすべての端末に入れる必要はありませんし、すべての端末が同じネットワークに属する必要もありません。できるできないの二択で考えるから設計が難しくなるのであり、必要な権限を細かく分けて設計することが重要です。
具体的にお願いします。風の息吹を感じれば〜 ですか?
具体的にお願いします。
基本的にDBは特定の場所からしかアクセスできないように設計するものです。ごく普通一般のシステム設計です。
システム設計としては一般的かも知れないけれど、システム運用としては全然一般的じゃないです。
顧客からの問い合わせがある度に専用端末へ出向いて、調べた内容を紙にメモして自席に戻り返信……とか、窓口業務の人はやってられないでしょ。
JTBは違った、ってだけだと思う。
個人のデスクに専用回線と一般回線の二台の端末を置いて、ってのは一般的かどうかはさておき現実に存在するパターンではありますね。JTBの様な業務だと文字列のコピペとかできないとツラいのかもしれないから、そういうシステムが許容されるのかは分かんないけど。
>顧客からの問い合わせがある度に専用端末へ出向いて、>調べた内容を紙にメモして自席に戻り返信……とか、専用端末に出向かなくてもいいよ。専用端末にアクセスすればいい。
あなたが運用現場を知らないから憶測でのみモノ言っているからそう考えるだけ。
クレデンシャルを入力出来るのは、シェル上で手動で実行した時に限る、
みたいな仕組みは、SELinuxにもPowerShellにも有るのでは無いでしょうか?
シェル上に手動で入力とリモート操作での入力とを区別できるような仕組みはどうしてもサーバ側ではなくクライアント端末側にソフトウェア実装が必要なので、結局クライアント端末が自由に改変できる状況下では時間稼ぎにしかならないですね。とはいえ外部との通信遮断などの対策に必要となる貴重な時間を稼げるのなら対策としては十分目的を果たしているのかもしれません。
確実(それもある程度でしかない)な対策はハード的に分離する方法しかないですが、実運用を考えると……というのは他の方がコメントされている通りだと思います。
DB操作系と受付業務系の実質隔離としては、
1. VMやsandboxによる一台のPC内での分離2. (漫画的だけど)DB操作系PCと受付業務系PCの二台使用、受付業務系PCからの文字列のコピペは、画面をカメラでモニタしつつ、OCRして取り込む。受け付業務系PCへは、USBキーボードをエミュレートして、文字列を送信。など。3. DB操作はコマンドの送信後、そのコマンドの実行を指紋認証で行う。ただし、指紋認証のデバイスはPCとは別のもの、別のネットワーク、あるいは、RS-232C等で行う。PCには指紋認証のデバイスは付属させない、指紋情報が盗まれないように。
などがありうるような気がします。
まぁ、システム管理、運用に携わったことがある人にしてみれば「ははぁん……」だけれど、一般の方々にとっては「ウィルス感染→流出!!」で危険の認識としては問題ないので、まぁその辺は「お察し」ということで(笑)
#いろいろずさんだったんじゃないかねぇ……
>#いろいろずさんだったんじゃないかねぇ……全個人情報がどこからでもアクセスできるサーバー上に置いてあったとかねぇ。住基ネット漏洩事件の例があるし。
何らかの方法で権限昇格したんじゃないですかね。内部から管理者に標的型メールを送るとか…。
逆にそれがなければ標的型メールへの対処なんかやりようがないでしょうね。 怪しいメールは開かない、添付ファイルが云々では誰かがやらかす。それは仕方ない。 しかし、旅行会社では個人情報のアクセスは社員全員が必要で、数はまぁふつうは一度に100前後あればいいだろうが、アクセス間隔は予想できない。セクションに分けるのも容易ではない。ビッグデータの分析をするなら全ファイルへのアクセスが必要。 なにより社員の手間を含めて結構なコストがかかる割に、流出の可能性は低く、流出しても批判はそこまで大きくない。 という訳で低コストな次善の策で個人が気を付けるように、となるのだが当然たまに漏れる。 結局、根本的な対策を取らなかったからなのにやらかした社員が責められ、繰り返される。 まぁ仕方ないでしょう。
あるいはブラウザやメーラーを仮想環境なりサンドボックスで動かせばいいのかもしれない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
個人情報へのアクセス制限があれば (スコア:2)
ウイルスに遠隔操作されても個人情報にアクセスできないような気がするのですが。。。
Re:個人情報へのアクセス制限があれば (スコア:4, 参考になる)
http://d.hatena.ne.jp/Kango/20160614/1465925330 [hatena.ne.jp]
サーバも感染していることから、経路としては
のようですね。
Re:個人情報へのアクセス制限があれば (スコア:2)
ウイルスに遠隔監視されてる端末上で、職員が個人情報へのアクセスを行うと……。
Re:個人情報へのアクセス制限があれば (スコア:2)
ウイルスに遠隔監視されてる端末上で、職員が個人情報へのアクセスを行うと……。
監視された状態で個人情報にアクセスすれば遠隔地でその情報を見れるのはわかるんですが、
790万人分にアクセスって相当な量ですので不思議に思って。
遠隔操作もあったにしても790万件のアクセスってなかなかできないですよ。
Re:個人情報へのアクセス制限があれば (スコア:2)
アクセスして得た個人情報それ自体を見ることが重要なのではなく、
その直前に認証してアクセス権限を取得する手続きを見ることが重要なのです。
Re:個人情報へのアクセス制限があれば (スコア:1)
データベースサーバに自由自在にアクセスできる権限のあるPCというのを外部と接触するネットワークから完全に隔離しておけば、漏洩はしなかったはず。
完全隔離と業務の効率化とを両立させるような仕掛けはありえないのでしょうか?
Re:個人情報へのアクセス制限があれば (スコア:1)
自由にアクセスできる端末と、制限付きアクセスを認められた端末で運用する事は比較的容易なはずです。
更に、メーラーをすべての端末に入れる必要はありませんし、すべての端末が同じネットワークに属する必要もありません。
できるできないの二択で考えるから設計が難しくなるのであり、必要な権限を細かく分けて設計することが重要です。
Re: (スコア:0)
具体的にお願いします。
風の息吹を感じれば〜 ですか?
Re: (スコア:0)
具体的にお願いします。
基本的にDBは特定の場所からしかアクセスできないように設計するものです。
ごく普通一般のシステム設計です。
Re: (スコア:0)
システム設計としては一般的かも知れないけれど、
システム運用としては全然一般的じゃないです。
顧客からの問い合わせがある度に専用端末へ出向いて、
調べた内容を紙にメモして自席に戻り返信……とか、
窓口業務の人はやってられないでしょ。
JTBは違った、ってだけだと思う。
Re: (スコア:0)
個人のデスクに専用回線と一般回線の二台の端末を置いて、ってのは
一般的かどうかはさておき現実に存在するパターンではありますね。
JTBの様な業務だと文字列のコピペとかできないとツラいのかもしれないから、そういうシステムが許容されるのかは分かんないけど。
Re: (スコア:0)
>顧客からの問い合わせがある度に専用端末へ出向いて、
>調べた内容を紙にメモして自席に戻り返信……とか、
専用端末に出向かなくてもいいよ。専用端末にアクセスすればいい。
Re:個人情報へのアクセス制限があれば (スコア:2)
システム設計としては一般的かも知れないけれど、
システム運用としては全然一般的じゃないです。
あなたが運用現場を知らないから憶測でのみモノ言っているからそう考えるだけ。
Re: (スコア:0)
クレデンシャルを入力出来るのは、シェル上で手動で実行した時に限る、
みたいな仕組みは、SELinuxにもPowerShellにも有るのでは無いでしょうか?
Re:個人情報へのアクセス制限があれば (スコア:2)
シェル上に手動で入力とリモート操作での入力とを区別できるような仕組みは
どうしてもサーバ側ではなくクライアント端末側にソフトウェア実装が必要なので、
結局クライアント端末が自由に改変できる状況下では時間稼ぎにしかならないですね。
とはいえ外部との通信遮断などの対策に必要となる貴重な時間を稼げるのなら
対策としては十分目的を果たしているのかもしれません。
確実(それもある程度でしかない)な対策はハード的に分離する方法しかないですが、
実運用を考えると……というのは他の方がコメントされている通りだと思います。
Re:個人情報へのアクセス制限があれば (スコア:1)
DB操作系と受付業務系の実質隔離としては、
1. VMやsandboxによる一台のPC内での分離
2. (漫画的だけど)DB操作系PCと受付業務系PCの二台使用、受付業務系PCからの文字列のコピペは、画面をカメラでモニタしつつ、OCRして取り込む。受け付業務系PCへは、USBキーボードをエミュレートして、文字列を送信。など。
3. DB操作はコマンドの送信後、そのコマンドの実行を指紋認証で行う。ただし、指紋認証のデバイスはPCとは別のもの、別のネットワーク、あるいは、RS-232C等で行う。PCには指紋認証のデバイスは付属させない、指紋情報が盗まれないように。
などがありうるような気がします。
Re:個人情報へのアクセス制限があれば (スコア:1)
まぁ、システム管理、運用に携わったことがある人にしてみれば「ははぁん……」だけれど、
一般の方々にとっては「ウィルス感染→流出!!」で危険の認識としては問題ないので、
まぁその辺は「お察し」ということで(笑)
#いろいろずさんだったんじゃないかねぇ……
Re:個人情報へのアクセス制限があれば (スコア:2)
>#いろいろずさんだったんじゃないかねぇ……
全個人情報がどこからでもアクセスできるサーバー上に置いてあったとかねぇ。
住基ネット漏洩事件の例があるし。
Re: (スコア:0)
何らかの方法で権限昇格したんじゃないですかね。内部から管理者に標的型メールを送るとか…。
Re: (スコア:0)
逆にそれがなければ標的型メールへの対処なんかやりようがないでしょうね。
怪しいメールは開かない、添付ファイルが云々では誰かがやらかす。それは仕方ない。
しかし、旅行会社では個人情報のアクセスは社員全員が必要で、数はまぁふつうは一度に100前後あればいいだろうが、アクセス間隔は予想できない。セクションに分けるのも容易ではない。ビッグデータの分析をするなら全ファイルへのアクセスが必要。
なにより社員の手間を含めて結構なコストがかかる割に、流出の可能性は低く、流出しても批判はそこまで大きくない。
という訳で低コストな次善の策で個人が気を付けるように、となるのだが当然たまに漏れる。
結局、根本的な対策を取らなかったからなのにやらかした社員が責められ、繰り返される。
まぁ仕方ないでしょう。
あるいはブラウザやメーラーを仮想環境なりサンドボックスで動かせばいいのかもしれない。