ファーストサーバデータ消失事件

このスレッドはクローズされています。記事の閲覧のみとなります。

ファーストサーバデータ消失事件

æ¥æï¼ 2012/06/27 09:49
ååï¼ ゆり

ファーストサーバというサーバ会社がデータを全消失させてえらい騒ぎになっていますがこれは他人事じゃないですね。自宅サーバーでも何年もやってるとそれなりに蓄積データがありますから、消えたら大変です。最近はRAIDにしている方も多いと思いますが、複数のHDDにデータがあるから安心と思ってると、ファーストサーバのようにスクリプトのミスや操作ミスで同時にデータ失う可能性がありますからね。RAIDでもバックアップは別のところに取らないとダメだとあらためて思いました。サイト上で更新されるCMSとかもデータを吸い上げて保存しないと怖いですね。レンタルサーバーとか使ってる人も要注意とか思いました。ファーストサーバ事件の原因の一つに「削除コマンドの範囲指定を忘れ」というのがありましたが、例えばrmコマンドを使い間違えたとかでしょうか？

Page: [1] [2] [3] [4] [5]

■ コンテンツ関連情報

Re: ファーストサーバデータ消失事件 ( No.16 )

æ¥æï¼ 2012/07/21 06:07
ååï¼ stranger
参照： http://ja.528p.com/

>ユーザー名とパスワードを仲間内で回しあうメンバーが変わる度にパスワードを変える必要がでてきますねそのままにしておいて、あとから不正アクセスに使われた例がよくあります＞サポートの切れたRHEL4が未だに現役で RHEL5からi586マシンがサポートされなくなったけどそういうわけではないですよねそろそろ、RHEL7の話題 RHEL５はサポートが10年に延長されましたが、サポート内容が期間によって異なります更新インストールイメージのサポートは今年でおしまい？ 5.9で最後？移行はupdateのみ？ Red Hat Enterprise Linuxのライフサイクル https://access.redhat.com/support/policy/updates/errata/

Re: ファーストサーバデータ消失事件 ( No.17 )

æ¥æï¼ 2012/07/23 15:28
ååï¼ Johann

strangerさん＞メンバーが変わる度にパスワードを変える必要がでてきますねそうですね。実際に退職者が出る度に変えてますよ。そのためのライブラリーも準備されてますしね。随分前に話題になった「バカの壁」ってまさにこれなんだなーと思う。最適解が他にあるのに、間違った解を導くためにリソースを割いてしまっている。さらに、最適解がなぜ最適なのか理解する頭脳も持っていない。

Re: ファーストサーバデータ消失事件 ( No.18 )

æ¥æï¼ 2012/07/27 14:35
ååï¼ ゆり

既存のシステムを直すというのは、手間(人件費等諸々)がかかるのは勿論ですし、やるとなるとリスクがあるから担当したくないとか。セキュリティーが上がってもそれ自体ですぐに利益が出るわけでもなし。結果、問題が起きるまで放置でしょうね。会社の上層部に見識のある方いて命令すればいいですが、下っ端や中間管理職は自分がリスクを負うのは嫌なので、必要性が解っていてもやりたがらない。本来やるべき部署が自己保身優先で知らないふりをするのは原発問題なんかでも同じで日本に蔓延しています。 >さらに、最適解がなぜ最適なのか理解する頭脳も持っていない。理解する頭脳を実は持っている、だけどやりたくないからアホなふりをしているとか(w (「知らなかった」「想定外だった」と言えば済むとどこかで思ってるんですよ)

Re: ファーストサーバデータ消失事件 ( No.19 )

æ¥æï¼ 2012/07/29 08:19
ååï¼ Johann

>結果、問題が起きるまで放置でしょうね。そうですね。そもそも問題として認識されていないです。そして行き着く所は「忙しい」「優先事項が他にある」の決まり文句。まーセキュリティの観点で言えばそこそこ高いですよ。恐ろしく不便で生産性ガタ落ちになる点に目をつむればね。サーバー毎にログインするユーザー名・パスが違うので、エンジニアは毎回パスワード表を開いてコピペ。 parallel sshなんて夢のまた夢ですね。

Re: ファーストサーバデータ消失事件 ( No.20 )

æ¥æï¼ 2012/07/29 10:48
ååï¼ 管理者

＞ Johann さんお久しぶりです。 > まーセキュリティの観点で言えばそこそこ高いですよ。恐ろしく不便で生産性ガタ落ちになる点に目をつむればね。 > サーバー毎にログインするユーザー名・パスが違うので、エンジニアは毎回パスワード表を開いてコピペ。これ、納得の文言ですね。セキュリティを高くすれば、生産性が落ちる。しかし、甘くすれば管理がずさんになる。パスワードを強化すれば、エンジニアは覚えておくのも大変なので何処かのテキストに残す。よって、セキュリティ観点からは問題。もっと問題なのは、グループ間で「XXXサーバのrootパスってなんだっけ？」って声を出して聞いている始末。側では客先と電話中のメンバーも・・・・・危機管理がなってない企業も多々あるのではないでしょうかね。うち（企業）は、ローカル（ネットワーク）だから大丈夫、って思っているのは大間違いであって、常に狙われていると思っていないと・・当サイトだって、たかが弱小なのに日々数十〜数百のアタックを掛けられてる状況で名の知れた企業では如何なものか？？因みに、もう興味無くなってしまったんですがスレタイの所は復旧したのでしょうか？？？

Page: [1] [2] [3] [4] [5]

■ その他

ページ先頭へ

Re: ファーストサーバデータ消失事件 ( No.16 )
æ¥æï¼ 2012/07/21 06:07 ååï¼ stranger 参照： http://ja.528p.com/ >ユーザー名とパスワードを仲間内で回しあうメンバーが変わる度にパスワードを変える必要がでてきますねそのままにしておいて、あとから不正アクセスに使われた例がよくあります＞サポートの切れたRHEL4が未だに現役で RHEL5からi586マシンがサポートされなくなったけどそういうわけではないですよねそろそろ、RHEL7の話題 RHEL５はサポートが10年に延長されましたが、サポート内容が期間によって異なります更新インストールイメージのサポートは今年でおしまい？ 5.9で最後？移行はupdateのみ？ Red Hat Enterprise Linuxのライフサイクル https://access.redhat.com/support/policy/updates/errata/
Re: ファーストサーバデータ消失事件 ( No.17 )
æ¥æï¼ 2012/07/23 15:28 ååï¼ Johann strangerさん＞メンバーが変わる度にパスワードを変える必要がでてきますねそうですね。実際に退職者が出る度に変えてますよ。そのためのライブラリーも準備されてますしね。随分前に話題になった「バカの壁」ってまさにこれなんだなーと思う。最適解が他にあるのに、間違った解を導くためにリソースを割いてしまっている。さらに、最適解がなぜ最適なのか理解する頭脳も持っていない。
Re: ファーストサーバデータ消失事件 ( No.18 )
æ¥æï¼ 2012/07/27 14:35 ååï¼ ゆり既存のシステムを直すというのは、手間(人件費等諸々)がかかるのは勿論ですし、やるとなるとリスクがあるから担当したくないとか。セキュリティーが上がってもそれ自体ですぐに利益が出るわけでもなし。結果、問題が起きるまで放置でしょうね。会社の上層部に見識のある方いて命令すればいいですが、下っ端や中間管理職は自分がリスクを負うのは嫌なので、必要性が解っていてもやりたがらない。本来やるべき部署が自己保身優先で知らないふりをするのは原発問題なんかでも同じで日本に蔓延しています。 >さらに、最適解がなぜ最適なのか理解する頭脳も持っていない。理解する頭脳を実は持っている、だけどやりたくないからアホなふりをしているとか(w (「知らなかった」「想定外だった」と言えば済むとどこかで思ってるんですよ)
Re: ファーストサーバデータ消失事件 ( No.19 )
æ¥æï¼ 2012/07/29 08:19 ååï¼ Johann >結果、問題が起きるまで放置でしょうね。そうですね。そもそも問題として認識されていないです。そして行き着く所は「忙しい」「優先事項が他にある」の決まり文句。まーセキュリティの観点で言えばそこそこ高いですよ。恐ろしく不便で生産性ガタ落ちになる点に目をつむればね。サーバー毎にログインするユーザー名・パスが違うので、エンジニアは毎回パスワード表を開いてコピペ。 parallel sshなんて夢のまた夢ですね。
Re: ファーストサーバデータ消失事件 ( No.20 )
æ¥æï¼ 2012/07/29 10:48 ååï¼ 管理者＞ Johann さんお久しぶりです。 > まーセキュリティの観点で言えばそこそこ高いですよ。恐ろしく不便で生産性ガタ落ちになる点に目をつむればね。 > サーバー毎にログインするユーザー名・パスが違うので、エンジニアは毎回パスワード表を開いてコピペ。これ、納得の文言ですね。セキュリティを高くすれば、生産性が落ちる。しかし、甘くすれば管理がずさんになる。パスワードを強化すれば、エンジニアは覚えておくのも大変なので何処かのテキストに残す。よって、セキュリティ観点からは問題。もっと問題なのは、グループ間で「XXXサーバのrootパスってなんだっけ？」って声を出して聞いている始末。側では客先と電話中のメンバーも・・・・・危機管理がなってない企業も多々あるのではないでしょうかね。うち（企業）は、ローカル（ネットワーク）だから大丈夫、って思っているのは大間違いであって、常に狙われていると思っていないと・・当サイトだって、たかが弱小なのに日々数十〜数百のアタックを掛けられてる状況で名の知れた企業では如何なものか？？因みに、もう興味無くなってしまったんですがスレタイの所は復旧したのでしょうか？？？