アカウント名:
パスワード:
少し設定を変えるだけで公開状態になるような場所に、個人情報を置くな。
俺もそう思う。ミスはあるし、ミスしたことに気づきにくい場所なのだから。
public と private の間に protected を設けよう
そういうアクセス権設定の概念を全否定するなら物理的に切り離すしかないんだけどな。事故らなければ不必要なコストが掛かる上に業務効率を大幅に下げることになるので無尽蔵に金が湧く組織以外は取れない選択肢。
仮想的にでも二重に後ろ側にあるネットワークに置けばいいだけじゃん。公開ネットワークと、DMZと、その後ろ側に分けるのはとても一般的。
S3にはどのネットワークに所属するみたいな概念はないのだが、正しく構築すれば- 明示的に与えられたアクセス権限が必要- 特定のVPC（ローカルネットワーク）からリクエストしたときだけアクセス可能とすることはできる。一度構築したらあとは設定を触れないようにIAM Userの権限を縛っておけばいい。
もちろん担当者は正しく設定したつもりだったでしょうに。だからこそ、ネットワークの分離の意味がある。
素人は黙っていろ。今どきのクラウドベースでウェブサービスを営む以上、どの場所であれ設定を少し変えれば公開状態になる。
今時、プライベートアドレスを振った非公開の仮想ネットワークを作るくらい、どこのサービスでもできるだろ。
的外れな意見ですね。非公開の仮想ネットワークに退避させるのはサーバへの直接的な侵入対策に有効なのであって今回のような設定ミスがあったとき漏洩を防ぐものではないんですよ。
ウェブベースで一般向けにサービス提供しているんだからどこかで顧客のアクセスに応じてデータを見せないといけない。サーバの奥深く、VPNの先にデータを入れていたとして結局パブリック側に取り出す口は開けざるを得ないのだから、その口の開け方の設定次第ってことです。そこがミスってたら仮想ネットワークだろうが何だろうが無意味です。
目的の重点をどこに置いているのかは設計思想によるだろうが、何段階かの接続を踏むものなら、1ヶ所の設定ミス程度では今回のような事故は起きなかった。フールプルーフを考慮しておかないと、必ずどこかで事故は起こるよ。利便性を取って安全性を犠牲にしていることを、再認識したほうがいい。
アホ担当者が設定をミスることがないように、ユーザーやグループに権限を割り当てればいいだけ。分掌していないのであれば、設計者がアホ。
×今どきのクラウドベースでウェブサービスを営む以上○俺が使ったことのある範囲のAWSの簡易な機能で営む以上
AWSのことよく知らないで書き込んでるでしょ。今回の原因となったS3もそうだけど、簡易どころかめちゃ奥深いし基本的に、AWSは「簡易じゃないもの」ほどトラップも多いので設定ミス・実装ミスによる漏洩リスクはむしろ上がるんだよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
設定を間違えたことが問題ではない (スコア:0)
少し設定を変えるだけで公開状態になるような場所に、個人情報を置くな。
Re: (スコア:0)
俺もそう思う。
ミスはあるし、ミスしたことに気づきにくい場所なのだから。
Re: (スコア:0)
public と private の間に protected を設けよう
Re: (スコア:0)
そういうアクセス権設定の概念を全否定するなら物理的に切り離すしかないんだけどな。
事故らなければ不必要なコストが掛かる上に業務効率を大幅に下げることになるので無尽蔵に金が湧く組織以外は取れない選択肢。
Re: (スコア:0)
仮想的にでも二重に後ろ側にあるネットワークに置けばいいだけじゃん。
公開ネットワークと、DMZと、その後ろ側に分けるのはとても一般的。
Re: (スコア:0)
S3にはどのネットワークに所属するみたいな概念はないのだが、正しく構築すれば
- 明示的に与えられたアクセス権限が必要
- 特定のVPC（ローカルネットワーク）からリクエストしたときだけアクセス可能
とすることはできる。
一度構築したらあとは設定を触れないようにIAM Userの権限を縛っておけばいい。
Re: (スコア:0)
もちろん担当者は正しく設定したつもりだったでしょうに。
だからこそ、ネットワークの分離の意味がある。
Re: (スコア:0)
素人は黙っていろ。
今どきのクラウドベースでウェブサービスを営む以上、どの場所であれ設定を少し変えれば公開状態になる。
Re: (スコア:0)
今時、プライベートアドレスを振った非公開の仮想ネットワークを作るくらい、どこのサービスでもできるだろ。
Re: (スコア:0)
的外れな意見ですね。
非公開の仮想ネットワークに退避させるのは
サーバへの直接的な侵入対策に有効なのであって
今回のような設定ミスがあったとき漏洩を防ぐものではないんですよ。
ウェブベースで一般向けにサービス提供しているんだから
どこかで顧客のアクセスに応じてデータを見せないといけない。
サーバの奥深く、VPNの先にデータを入れていたとして
結局パブリック側に取り出す口は開けざるを得ないのだから、
その口の開け方の設定次第ってことです。
そこがミスってたら仮想ネットワークだろうが何だろうが無意味です。
Re: (スコア:0)
目的の重点をどこに置いているのかは設計思想によるだろうが、何段階かの接続を踏むものなら、1ヶ所の設定ミス程度では今回のような事故は起きなかった。
フールプルーフを考慮しておかないと、必ずどこかで事故は起こるよ。
利便性を取って安全性を犠牲にしていることを、再認識したほうがいい。
Re: (スコア:0)
アホ担当者が設定をミスることがないように、ユーザーやグループに権限を割り当てればいいだけ。
分掌していないのであれば、設計者がアホ。
Re: (スコア:0)
×今どきのクラウドベースでウェブサービスを営む以上
○俺が使ったことのある範囲のAWSの簡易な機能で営む以上
Re: (スコア:0)
AWSのことよく知らないで書き込んでるでしょ。
今回の原因となったS3もそうだけど、簡易どころかめちゃ奥深いし
基本的に、AWSは「簡易じゃないもの」ほどトラップも多いので
設定ミス・実装ミスによる漏洩リスクはむしろ上がるんだよ。