アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
閉鎖空間 (スコア:2, 興味深い)
実際に、嫌がらせ目的でやられました。
仕事がまともに進められない、ちょっとしたことで騒ぐ人がいまして、今回もこちら側が穴拭きをやったのですが。
Webで数日で作り上げる必要があって、間に合わないことはわかってました。
なので、機能を少しずつあげようという形にしたのですが。
Webで公開して数日して、社内でWebの問題点で誹謗中傷してきました。そこだけでは満足しなかったので、2chで内部事情をばらしまくりました。そのときからWebへの攻撃がひどくて、攻撃がある
Re:閉鎖空間 (スコア:0)
内部セキュリティ対策しなきゃいけない段階だというのに、
http://www.caj.co.jp/press/2003/10/research.htm [caj.co.jp]
情報を管理するシステムのベンダーに、報告不足という脆弱性があっちゃ始まりませんね。
Re:閉鎖空間 (スコア:0)
その事自体の必要性は否定しませんが対策が
>情報を管理するシステムのベンダーに、報告不足という脆弱性がない
とは、特に元コメントで例示されている社内のトラブルメイカーに対しても、
高木氏の想定している運用条件においても、有効性がとぼしく、
ちょっとこじつけがましいように思います。
脆弱性の認識がユーザ想いで報告不足が無い事は、望ましいことというのは間違いがないのですけど。
会社に損害を与えても構わないと言う動機の持ち主に、すでにアクセス権をあたえている。
システムの脆弱性をつくような手順を踏む必要が無い相手に、妨害可能な内部統制の仕組み
というのはシステムとそのベンダーがどうこう出来る領域ではないはずです。
実際、元コメント(#1010303)で例示されているトラブルメイカーも
そのようなベンダー泣かせの手段はとっていません。
どっちかというと、元コメントの例から得られる教訓は流行だからという理由で
ブログを公開して炎上してしまうような安易なシステム化信仰の弊害問題に似ています。
信頼できない相手にまで、システムを公開せざるを得ない事情を飲み込むしかない、
という環境がある事は想像つきますし、同情もしますけどね。
#元ACが実はサイボウズの内情暴露だったらまた違う話になりそうだけど。
Re:閉鎖空間 (スコア:0)
サイボウズとは関係ないですよ。
社内のイントラであろうが、インターネットに接続されたイントラであろうが、甘く考えると攻撃されますよという意味でとってもらえればいいだけです。
イントラであっても、VPNの拠点がどうしても多いため、インターネットに接続しなければならないケースもあるかと思います。
予算の問題とか、運用の問題をも含めて。
ひどいケースはIDとパスワードを他の人に教えちゃう問題もあったし。
# いまだにセキュリティ観念の薄い企業も多いのが事実ですが。