アカウント名:
パスワード:
一受託業者が決めるべき問題じゃないね。そのシステムのセキュリティポリシに従って決まる。
より良いシステムになるよう助言はした方がよいと思うけどね。
ところで、これって、サーバ(やクライアント)毎のパーソナルファイアウォールの話だよね。設定できるなら、設定した方がいいとは思うね。しかし、ネットワークで適切に守られていれば、それで十分と言う考え方もある。それこそセキュリティポリシだ。
パーソナルファイアウォールと同様の問題で、SELinuxをどうするか、って話はあるよね。SELinuxを無効にしてるのをよく見るけど…
無効化しなければならない理由が明確にあるのならその選択肢もありうる。しかし面倒を避けるため、ってだけなら唯の手抜きだしそれ自体は僅かで他が問題なければ影響ないとしても確実にセキュリティ下げてはいるんでそのリスクと何を比べた判断なのか次第だと思う
手抜きだと一概に言えないほどSELinuxはひどいでしょ。意図的にわかりにくく設定しづらくしてセキュリティを高めているつもりなのかと勘ぐりたくなる。技術、知識、意識がうんぬんと言うより新しいアクセス制御のソフトをつくった方がましに思える。
SELinuxの連中(NSA)が新しいアクセス制御ソフトの導入を全力で妨害していたのをブチ切れて解決してくれたLinusさんマジイケメン
つまりTOMOYO Linuxを有効にすればいい。さすがに仕事では使ったこと無いけど、個人で運用してたサーバには使ってたな。
AppArmorとかどうですか?
そのリスクと何を比べた判断なのか次第だと思う
大抵の場合は単なる手抜き、というのは同意として。
リスクと管理負荷を比べた判断、という言い訳はよく聞くね。
言い訳じゃなくて、適切な判断だと思いますよ。それこそセキュリティポリシでしょ?
言い訳じゃなくて、適切な判断だと思いますよ。
適切な判断のケースもあるし、そうでない場合もあるよ。
例えば、ちゃんと調査して設定すればOKなのに、工期を確保できないがために、「リスクと管理負荷を比べた判断」ということにした、というケースがある。受託業者も工数が減るし、委託側も工期を守れるなら、と結託した結果そーなるケースね。
「ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない」だって適切な判断なのに、そういう誤摩化しをする人の考え方がよくわからない。
ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない
結果、セキュリティが不十分になります、と説明しなければならないことになっちゃうから、とかですかね。実は、調査する気もその能力もない、って話だったりするとなおさら。
あと、前例を破ると、自分たちの過去の仕事が不十分だったことを認めなきゃいけなくなっちゃうから、とかね。
セキュリティが十分かどうかの説明は当然するよね。妥当かどうかは顧客が決める。
顧客と一口に行っても、一体ではないからね。誰が誰に説明するのか、って問題になる。業者が直接付き合うのは、IT部門の担当者で、会社の経営層に説明するのは、そのIT部門のトップだったり。そーなると、みょーな社内力学とかが働いたりして。
委託される側が社内力学の事まで気を遣うのが過剰なんでしょうね。私の場合は「期間と金があれば出来るが、懐事情は分かっている。社内向けの説明はよろしく」で通しているけど問題になったことはないですね。稀なケースではあるけど顧客の経営陣へ説明する場合も、正直に言う。判断するのはその人たちの役目で、そのための情報に嘘を混ぜてもろくな事にならない。金も期間もくれないところとは、どうせ将来的にもうまくやれないので早期撤収するという自社ポリシーのおかげでもありますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
セキュリティポリシ次第 (スコア:5, 興味深い)
一受託業者が決めるべき問題じゃないね。
そのシステムのセキュリティポリシに従って決まる。
より良いシステムになるよう助言はした方がよいと思うけどね。
ところで、これって、サーバ(やクライアント)毎のパーソナルファイアウォールの話だよね。
設定できるなら、設定した方がいいとは思うね。
しかし、ネットワークで適切に守られていれば、それで十分と言う考え方もある。
それこそセキュリティポリシだ。
パーソナルファイアウォールと同様の問題で、SELinuxをどうするか、って話はあるよね。
SELinuxを無効にしてるのをよく見るけど…
Re:セキュリティポリシ次第 (スコア:0)
無効化しなければならない理由が明確にあるのならその選択肢もありうる。
しかし面倒を避けるため、ってだけなら唯の手抜きだし
それ自体は僅かで他が問題なければ影響ないとしても確実にセキュリティ下げてはいるんで
そのリスクと何を比べた判断なのか次第だと思う
Re:セキュリティポリシ次第 (スコア:2, 興味深い)
手抜きだと一概に言えないほどSELinuxはひどいでしょ。
意図的にわかりにくく設定しづらくしてセキュリティを高めているつもりなのかと勘ぐりたくなる。
技術、知識、意識がうんぬんと言うより新しいアクセス制御のソフトをつくった方がましに思える。
Re:セキュリティポリシ次第 (スコア:1)
SELinuxの連中(NSA)が新しいアクセス制御ソフトの導入を全力で妨害していたのをブチ切れて解決してくれたLinusさんマジイケメン
Re: (スコア:0)
つまりTOMOYO Linuxを有効にすればいい。さすがに仕事では使ったこと無いけど、個人で運用してたサーバには使ってたな。
Re: (スコア:0)
AppArmorとかどうですか?
Re:セキュリティポリシ次第 (スコア:1)
そのリスクと何を比べた判断なのか次第だと思う
大抵の場合は単なる手抜き、というのは同意として。
リスクと管理負荷を比べた判断、という言い訳はよく聞くね。
Re:セキュリティポリシ次第 (スコア:1)
言い訳じゃなくて、適切な判断だと思いますよ。
それこそセキュリティポリシでしょ?
Re:セキュリティポリシ次第 (スコア:1)
言い訳じゃなくて、適切な判断だと思いますよ。
適切な判断のケースもあるし、そうでない場合もあるよ。
例えば、ちゃんと調査して設定すればOKなのに、工期を確保できないがために、「リスクと管理負荷を比べた判断」ということにした、というケースがある。
受託業者も工数が減るし、委託側も工期を守れるなら、と結託した結果そーなるケースね。
Re: (スコア:0)
「ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない」だって適切な判断なのに、そういう誤摩化しをする人の考え方がよくわからない。
Re:セキュリティポリシ次第 (スコア:1)
ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない
結果、セキュリティが不十分になります、と説明しなければならないことになっちゃうから、とかですかね。
実は、調査する気もその能力もない、って話だったりするとなおさら。
あと、前例を破ると、自分たちの過去の仕事が不十分だったことを認めなきゃいけなくなっちゃうから、とかね。
Re: (スコア:0)
> 結果、セキュリティが不十分になります、と説明しなければならないことになっちゃうから、とかですかね。
時間くれれば（導入及びその他への影響の）調査して実施するけどその工期（と予算）は与えてくれないからできないっていうだけでしょ。
セキュリティが十分かどうかの説明は当然するよね。
妥当かどうかは顧客が決める。
> 前例を破ると、自分たちの過去の仕事が不十分だったことを認めなきゃ
仕事でこういう話扱ってればわかると思うけど、これは逆。
これまでやっ
Re:セキュリティポリシ次第 (スコア:1)
セキュリティが十分かどうかの説明は当然するよね。
妥当かどうかは顧客が決める。
顧客と一口に行っても、一体ではないからね。
誰が誰に説明するのか、って問題になる。
業者が直接付き合うのは、IT部門の担当者で、会社の経営層に説明するのは、そのIT部門のトップだったり。
そーなると、みょーな社内力学とかが働いたりして。
Re: (スコア:0)
委託される側が社内力学の事まで気を遣うのが過剰なんでしょうね。
私の場合は「期間と金があれば出来るが、懐事情は分かっている。社内向けの説明はよろしく」で通しているけど問題になったことはないですね。
稀なケースではあるけど顧客の経営陣へ説明する場合も、正直に言う。
判断するのはその人たちの役目で、そのための情報に嘘を混ぜてもろくな事にならない。
金も期間もくれないところとは、どうせ将来的にもうまくやれないので早期撤収するという自社ポリシーのおかげでもありますが。