アカウント名:
パスワード:
----- Team Slashdot Japan [tripod.co.jp]に参加しよう。
逆に高価なハードほど試験環境は用意しやすいですよ。購入時の予算に試験用の低スペックな機械が織り込まれていたりしますので。
もちろん、担当役員もセキュリティホールによる
実際、顧客データの漏洩事
だから件の責任にしてもきちんとセキュリティーに対する知識
Googleとか/.Jとか止まってるとこ見たことないんだけど 一台ずつ切り離してパッチ当ててるのかな?
当ててる間はセキュリティホール残ったままなんだよね。 それとも徹底的な試験でApacheよりずっとセキュアな特製 サーバ使ってるとか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
実際問題として (スコア:2, すばらしい洞察)
私の場合 (スコア:2, 興味深い)
というのも、テストできるような別マシンは存在しないためです。
また、仮に別マシンが用意されても、サーバ管理を仕事としているわけではないので、メインサーバと同様の環境を構築して動作確認をするのは時間的に厳しいです。
そこでパッチが出てもすぐには適用せず、MLやwebでの情報を数時間後にチェックし、問題が挙がっていないようなら適用します。
もちろん、これでは不完全であるのはわかっているのですが、、、
お金は貰ってないとは言え、不用意にパッチを当ててサービスを止めてしまうのはまずいし、 かといって他人様に迷惑をかけるわけにはいかんのでこんな方法をとっています。
Re:私の場合 (スコア:1)
でも、いざというときには迅速にサービスの停止を決断できるというのが、実は一番重要ではないかと思うのですよ。
# そのあたりの見極めができるのが真の管理者かと。
-----
Team Slashdot Japan [tripod.co.jp]に参加しよう。
サービスの停止の判断 (スコア:1)
責任者をサービス停止の判断をする役目にします。
検出したときのアクション、パッチが発表されたとき
のアクション、適用までの手順も明らかにしてます。
文章にして。
サービスを停止する判断は、サーバ管理者には無理で
しょう?(社内利用者しかいないとしても、停止の判
断はある程度の役職の人でないと。末端利用者は、自
分の便利だけを要求するから。)
サーバ管理者の役割は、明文化しておいたほうが良い
と思います。
Re:サービスの停止の判断 (スコア:1)
当然、上司の責任で止めます。# そうでないと恐くてできないです。
ただし、停止決定の手続きはかなり簡略化されていて(判断に加わる人も少ない)、迅速に停止できるようになっています。
おっしゃられるように、不測の事態に備えて、具体的にどのような対応するのかや誰がどのような権限を持つのかを明文化しておくというのが重要だと思います。
-----
Team Slashdot Japan [tripod.co.jp]に参加しよう。
Re:実際問題として (スコア:1)
いわゆるテスト環境マシンが用意しにくいってのが有りますね。
そういう意味では、安いpcに、インストール単位でライセンス料とられるわけでもないオープンソースなos/アプリという組みあわせは、
いろいろ幸せになりますね。
俺んとこもプロプラかつLinux非対応な某鯖ソフトがネックでねえ…
Re:実際問題として (スコア:0)
| いわゆるテスト環境マシンが用意しにくいってのが有りますね。
逆に高価なハードほど試験環境は用意しやすいですよ。購入時の予算に試験用の低スペックな機械が織り込まれていたりしますので。
Re:実際問題として (スコア:0)
Re:実際問題として (スコア:1)
恐ろしい? (スコア:0)
とうぜん、サーバーは止めて作業してるんだよね? そうは読めないけど。
Re:恐ろしい? (スコア:0)
というプライオリティの仕事も多いですよ。
ヤバ目の時はリアルタイムで監視はするけど、サービス停止には管理者権限
では出来なくて、もっと上位の人間の承認が必要だったり。
で、今のところサービス停止の許可は出たことありません。
もちろん、担当役員もセキュリティホールによる
Re:恐ろしい? (スコア:1)
>と計算されているのでそこの計算がくつがえらない限りは今の体制のままでしょう。
つまり会社組織というものの問題ですね。
>別に会社批判では無いですし
いや、立派な(=誰に憚ることもない)批判でしょう。
特定企業じゃなくて企業というもの一般に向けられた批判ではありますが(もちろん、だから悪いということは全然無い)。
Re:恐ろしい? (スコア:0)
> セキュリティーホールによる会社への実害予想見積り<停止する事による確実な損害
> と計算されている
顧客情報を抜かれてもかまわないと?
Re:恐ろしい? (スコア:1)
セキュリティーホールによる会社への実害予想見積り>停止する事による確実な損害
となって止めるんではないかと。
そうでもないなら、上の人は納得しないのでしょう。
Re:恐ろしい? (スコア:0)
その会社の顧客名簿はもう盗まれてるかも。
表沙汰にならないだけで。
Re:恐ろしい? (スコア:1)
どうやって上司を説得するのよ?
あまりに机上の空論多すぎ
まず
a : 管理者のコスト
b : crackされた時のコスト
c : crackされる確率
d : crackされて、それに気づかない確率
この辺をちゃんと出してから考えなよ。
んで、あなたはそれぞれの数字を客観的なデータを元に示さ
ないと、他人を説得はできませんよ?
特にb,c,d は説明しにくいと思うが・・・
たとえば実際に踏み台にされてどっかを攻撃するって事件があって、
それの損害賠償を要求されたケースってばどんぐらいあるもんなんでしょう?
もちろん日本限定の話ですよ?
Re:恐ろしい? (スコア:0)
>それの損害賠償を要求されたケースってばどんぐらいあるもんなんで
>しょう?
そうですね。
その実例が無い限り、セキュリティーホールによる損害計算は机上の
空論に過ぎないって事になるかと思われます。
実際、顧客データの漏洩事
Re:恐ろしい? (スコア:0)
ワームは自分のところに来るまでに存在が判明している「可能性」があるのに対して、クラッカーの標的になる場合は普通前触れ無し。セキュリティホールがあれば対処できない(対処できるのであればセキュリティホールではない)し、クラックされたことに気づけないような穴であれば、実はすでにクラックされているってこともありえる。
さほど宣伝してもいない、有名でもない個人サイトなら標的になる「可能性」は低いでしょうけど、規模の大小にかかわらず「会社」のサイ
Re:恐ろしい? (スコア:0)
いいえ、もちろんそれは避けるべき事となってます。
が、その為に万全な対策を行う事により派生する費用が、実際に
顧客情報を抜かれたりするリスクの確率に比べて大きすぎると計算
されているだけです。
完全を期さないものはリスクを考えないと受け取るのは短絡的過ぎです。
だから件の責任にしてもきちんとセキュリティーに対する知識
Re:恐ろしい? (スコア:0)
Googleとか/.Jとか止まってるとこ見たことないんだけど 一台ずつ切り離してパッチ当ててるのかな?
当ててる間はセキュリティホール残ったままなんだよね。 それとも徹底的な試験でApacheよりずっとセキュアな特製 サーバ使ってるとか?
Re:恐ろしい? (スコア:0)
サーバを複数台にしている場合が殆どです。
アップデート中はロードバランサの設定をいじってロードバランスの対象から
外しておけば、外から見れば反応が多少鈍くなる程度でサービスが止まらずにすみます。
Re:恐ろしい? (スコア:0)