[RPA]PC自動化技術総合スレ[効率化] Part.7

■ このスレッドは過去ログ倉庫に格納されています
2019/11/19(火) 20:35:47.34ID:K8abzL+c
語りましょう
次スレは>>950がたててね
2020/01/12(日) 08:37:58.88ID:8exfRg1S
ステータスコード見て判断すれば良いじゃんってわけでもないの？
2020/01/12(日) 10:49:10.00ID:BjDdiYvI
セキュリティ意識、低すぎだろ
ステータスコードなんてのは、通信中に明らかなエラーはなかったね、程度の認識でいい
ステータスOKならそこから更に、中間者攻撃がなかったか、データ破損がなかったか、等のより精度の高いチェックをするのが当たり前だ
それで、具体的には、信頼できるハッシュ値と比較する方法が精度面、安全面、コスト面でベストだ
2020/01/12(日) 11:25:14.46ID:3agDZCYl
セキュリティ意識高い系まだ騒いでんのか
2020/01/12(日) 11:29:55.46ID:bSfOvwvy
>>765
なんでこの文脈でセキュリティ意識が出てくるのかよくわからん。
たかだかエビデンスのバックアップする程度の作業だぞ。
2020/01/12(日) 11:34:20.33ID:bSfOvwvy
極論言えば、ダウンロードにErrorがなければよいだけであって、中身が変わってたとしても、原本が銀行サイトにあるんだから問題発覚時に突き合わせすればいいだけでしょ。
2020/01/12(日) 11:47:20.67ID:ak9RyXpr
問題が発覚すれば幸運
発覚しないことも多い
うっかり税金がらみだと追徴課税されてしまうが、うっかりで済めばいいけど
2020/01/12(日) 11:50:15.11ID:BjDdiYvI
これだから意識低いやつは
バックアップは大元が消えたり、壊れた時のものだ
なにか問題があっても、極論、大元があるからいいじゃん、なんて考え方は本末転倒だ
2020/01/12(日) 11:51:34.06ID:BjDdiYvI
>>767
データ改ざんリスクはセキュリティの話題だろが
2020/01/12(日) 11:56:46.77ID:yD0L96jY
手作業の時もやってるのかね
2020/01/12(日) 12:02:54.37ID:ak9RyXpr
なかなか発覚しない問題の例(空想世界の出来事で現実とは無関係)
問題とは：
　　銀行のシステム障害の案内を弊社のRPAが気づかずデータ差し替えできなかった
ーーーーー
Home　＞　お客様へ
先日の帳票が間違ってたんよ。ごめんね

原因：うちのRPAがしくったけど気づかなかった
しくった内容
　　：いつのまにか法律が変わってあちこち変更で、うちの帳票アップロードRPAがぱにくった

対処：当該RPAは停止しますた
　　：ERPの出力を人間による二重チェック後にアップロードする運用に変更
　　：法律が変わったらアラームをだすRPAの稼動を開始しますん

お客様へのお願い
　　：ここ(URL)からダウンロードして差し替えてくれよう年度末まで公開中
　　：もともとのダウンロードデータを差し替えるシステムが未実装なので差し替えらんない御了承しなさい
2020/01/12(日) 12:04:35.22ID:bSfOvwvy
>>770
>>771
あほすぎる。
大元が壊れても意味があるデータなら、データに署名が入ってるはずだからそれを検証しとけばいいし、そうでないなら大元が壊れたらごみになる。
リスクを正しく判断するのがセキュリティの基本だぞ。
2020/01/12(日) 12:08:27.48ID:BjDdiYvI
>>774
バカすぎ
今は署名もハッシュもない状況を議論してんだよ
2020/01/12(日) 12:12:55.10ID:bSfOvwvy
>>775
の本後嫁「そうでないなら大元が壊れたらごみになる。 」
2020/01/12(日) 12:13:35.09ID:bSfOvwvy
>>776
ひどいなｗ「日本語読め」なｗ
2020/01/12(日) 12:16:04.96ID:BjDdiYvI
こいつやべえな

バ　ッ　ク　ア　ッ　プ

の話題なのに

大　本　が　壊　れ　た　ら　ダ　メ

とか本末転倒すぎて話にならん

大　本　が　壊　れ　た　時　の　話

してんだよバカ
2020/01/12(日) 12:27:06.70ID:bSfOvwvy
>>778
壊れたらどうやって「大元と同じだった」って証明するんだよ。
ばかｗ
2020/01/12(日) 12:37:55.95ID:/os/mmOS
>>779
バカの世界チャンプか？
ダウンロード後に大元と同じことを確かめるにはどうすればいいのか？ってことを議論してんだろが
壊れた後の話にすりかえてんじゃねえよダウンロード直後には大元は生きてる前提だろが
スタート地点に戻って質問をよく見直してこい
そしてもう帰ってくるな
2020/01/12(日) 12:47:02.01ID:bSfOvwvy
>>780
あれ？問題すり替わってるぞ。
問題だったのは、

> 銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？

> 「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」
という判定をどうすればいいか、思いつかない

で、別に大元と同じことを確かめたいって要件はない。
その要件はお前がいい出しただけで、俺がリスク判定的に「無駄」って指摘したんだけど？

もう一度言おうｗ「日本語読め」ｗ
2020/01/12(日) 12:57:43.04ID:/os/mmOS
>>781
はぁやれやれ
ダウンロードに成功したってことは大元と同じデータが手元にあるって事だ
つまりこれはローカルとリモートのデータの同値性をいかにして担保するかという問題なんだよ
てめえが関わると要件漏れで大惨事まっしぐらだな
2020/01/12(日) 13:10:11.02ID:bSfOvwvy
>>782
> つまりこれはローカルとリモートのデータの同値性をいかにして担保するかという問題なんだよ

だから、それ言い出したのお前だし、意味がないって言ってるんだけど。
大元がぶっ壊れたら無駄になる程度のデータなら、別にダウンロード元の厳密な検証とか必要ないし
計算が合わないとかのシステム上の不整合で検証するのがまっとうだろ。

ダウンロード時のセキュリティとか、ブラウザレベルの実装で問題ない。

なんか、本気で言ってるっぽいからカワイソウになってきたわ。
2020/01/12(日) 13:30:43.81ID:/os/mmOS
>>783
厳密な検証が必要ないなら迷うところなんてないんだから質問しねえわ
つかブラウザでセキュリティ十分とか言ってるなら本気でアホだぞ
2020/01/12(日) 13:44:00.39ID:bSfOvwvy
>>784
質問はコレ

> 銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？

> 「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」
という判定をどうすればいいか、思いつかない

お前、全然ずれたこと言ってんのよ。

> つかブラウザでセキュリティ十分とか言ってるなら本気でアホだぞ

ブラウザレベルって言うよりももっと限定的に「使用する証明書選択をただしくね」ぐらいだな。
セキュリティ意識すればするほど要件的に無駄が分かってくる。

それよりも、>>773 とかをどう拾うとかのほうが考察としては面白い。
多分、ログイン後の「需要なお知らせ」系の処理だと思うけど、しんどそう。
2020/01/12(日) 13:57:39.24ID:/os/mmOS
>>785
ずれてんのはお前な
セキュリティを意識してないから要件漏れだらけだ
773は今は別の問題で誰も議論してない
2020/01/12(日) 14:00:43.14ID:bSfOvwvy
>>786
俺の言ってること、理解できないんでしょ？
もう君出てこなくていいよｗ

それより >>773 を深めたほうがスレ的に面白い。
突発的に出てきそうなお知らせって、みんなどうやって拾おうとしてる？
2020/01/12(日) 14:23:22.55ID:BrY9V3ck
>>787
そっくり返すわ
お前も出てくんな
2020/01/12(日) 14:36:27.29ID:bSfOvwvy
>>788
だって君、質問も理解できてないし、リスク分析もできないし、勝手に条件追加するし、勝手に要件も追加しようとする。
邪魔なだけじゃん。
プロジェクト炎上屋さんでしょ。いらんわｗ
2020/01/12(日) 14:39:42.55ID:wzOQ6goX
>>789
だって君、質問も理解できてないし、リスク分析もできないし、隠れた条件見逃すし、要件お漏らしするし
邪魔なだけじゃん
プロジェクト炎上屋さんでしょ。要らんわ
2020/01/12(日) 14:54:13.91ID:bSfOvwvy
>>790
ナンだよ隠れた条件って。勝手に付け加えるなｗ
質問者からそんな追加条件ヒアリングできてないぞ。

お前、ずーと一人でスコープがずれてんのよ。
だから会話にならんし、人の言うことが理解できない。

そろそろ学習しろ。何回同じこと繰り返してるの？
2020/01/12(日) 15:06:00.25ID:khQ0wJGz
>>791
んなこと言ってるから本来必要な要件をお漏らししてあとで大事故に繋がるんだよ
相手が言ったことだけを鵜呑みにするな
それは何も考えないバカのやりかただ
2020/01/12(日) 15:18:55.74ID:bSfOvwvy
>>792
> 相手が言ったことだけを鵜呑みにするな

ちがうぞ。必要なら相手に提案して「ヒアリング」するんだよ。
で、エビデンスを残す。
勝手に追加するのはプロジェクトとして最悪の結果を残すし、そんなやつはプロジェクトにいらない。

だれも必要としていない提案すらまともでない内容を勝手に追加するな。

今回だと、

> 銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？

> 「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」
という判定をどうすればいいか、思いつかない

に対して、なぜ、

> ステータスコードなんてのは、通信中に明らかなエラーはなかったね、程度の認識でいい
ステータスOKならそこから更に、中間者攻撃がなかったか、データ破損がなかったか、等のより精度の高いチェックをするのが当たり前だ

みたいな話が出る？
そもそもお前の言ってるステータスコードが「HTTPステータスコード」なら、このコメントすら間違ってるんだけど？
2020/01/12(日) 15:40:20.21ID:BtWuREj/
>>793
つうか前から思ってたがここはプロジェクトじゃねえぞ間抜け

ヒアリングしてないのはお前も同じ
質問者の発言は「ダウンロード成功したかどうか判断方法がわからない」だけだ
ダウンロード成功の定義が定まってない以上は過不足を論じることはできない
お前は余計な要件を追加するなというがそれが余計かどうかもわからん
俺が言うようにお前が必要な要件を勝手に無視してるかもしれん

リアルなプロジェクトでない掲示板ではよくあるシチュエーションだが質問者が議論に参加する気がない場合は平均的なシチュエーションを想定して論じるしかない
となると答えは信頼できるハッシュ値との比較が妥当なところだろとなるわけだ

HTTPステータスコードと誰かが言ったか？
2020/01/12(日) 15:45:24.57ID:BtWuREj/
つうかステータスコードをHTTPステータスコードと読み替えても特に問題ないだろそこ
2020/01/12(日) 15:55:29.27ID:bSfOvwvy
>>792
> ヒアリングしてないのはお前も同じ

そうそう。。だから提示された内容に対してのみコメントするようにしている。
だから余計な追加はしてない。

> ダウンロード成功の定義が定まってない以上は過不足を論じることはできない

そうそう。過不足を論じるな。

> リアルなプロジェクトでない掲示板ではよくあるシチュエーションだが質問者が議論に参加する気がない場合は平均的なシチュエーションを想定して論じるしかない

そうそう。分かってんじゃん。
ただ、平均が何かはシュチュエーションによる。
わからない場合は、「提示された内容で」進めるのがズレないコツ。
この場合は、「銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたい」っていうよくあるダウンロード案件。

> HTTPステータスコードと誰かが言ったか？

ナンのステータスコードを指したんだ？(これがヒアリング)

> 信頼できるハッシュ値との比較が妥当なところだろとなるわけだ
ならねーよばかｗ
なんでそこで飛ぶｗ

ところで、

> 今は署名もハッシュもない状況を議論してんだよ

そんな条件は、だ・れ・が・決めた？
2020/01/12(日) 16:06:16.36ID:gAizTjEJ
すげえ長々とやり合ってる所申し訳ない
>753、>>758の話だけ見ると
>「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」
単純にファイルダウンロードに成功したかどうかだけなら
とりあえず日付でファイル名作って存在チェックだけやればええんやないの？
セキュリティ面の話はその次のステップじゃ？
2020/01/12(日) 16:11:41.42ID:gAizTjEJ
ぶっちゃけ要件なんて後出しでコロコロ変わるんだから
・ツールでやりたい事（現行業務のヒアリング、自動化のフロー/処理の流れの策定）
・その上で必要なエラーチェック処理（ファイル存在チェック、アクセス可否チェック、整合性チェック等など）
正直、やりたい事も分からずに互いの妄想だけで殴り合ってるのは不毛すぎるわ
2020/01/12(日) 16:14:25.30ID:bSfOvwvy
>>797
これ、今日ダウンロードしたファイルはホントに今日の作成のモノなの？って疑問だから、ダウンロード日の比較だとちょっとまずい。(ダウンロードファイル名に作成日付が入っていればいいけど。)

で、前日ファイルと当日ファイルの内容比較なら、ハッシュの比較でいいんでは？ってのがコメントとしてついてる。

意識高い君がズレたこと言ってるから、ミスリードになってるけど、元の文脈はそんな感じ。
2020/01/12(日) 16:21:20.58ID:gAizTjEJ
>>799
ああ、そういう流れでハッシュ値比較が出たのか
個人的にはファイルのタイムスタンプで見たいかな
あれなら作成日時とれるし
2020/01/12(日) 16:22:25.75ID:BtWuREj/
>>796
提示された内容に対してのみコメントとかよく言えたもんだ
お前の論調は余計な要件を増やすなだろ
先程も言ったが要件が定まってないのに要件を増やすなとは言うことはできない
つまりお前も脳内で勝手に定めた要件を基にして発言しているんだよ
それは提示された内容ではない

提示された内容は「銀行サイトからダウンロードする際にダウンロード成功を判定する方法」だ
何を持ってダウンロード成功とみなすかは未定義な

HTTPモジュールの返すステータスあるいは投げる例外だよ
バカでもわかると思うがHTTPリクエストの失敗要因はネットワークやサーバーサイドだけじゃねえぞ？

妥当だぞ
セキュリティが絡むファイルのダウンロードを必要とする場面ではハッシュ値の比較はポピュラーな解決策だ
コストと安定性と精度の観点から見てバランスがいいんだよ
もちろんサービス側がハッシュ値を公開してる前提だが
デジタル署名もないハッシュ値も無い場合に比較的有効な確認方法は形式チェックと複数回ダウンロードだが
形式チェックはエラーが小さいと意外とチェックに引っかからない場合がある
複数回ダウンロードはファイルダウンロードの通信経路が保護されてる前提だがエラー検出の精度はかなり高い
2020/01/12(日) 16:26:38.27ID:BtWuREj/
>>797
ファイルが存在するかだけじゃ駄目だ
ダウンロードに失敗してもファイルが残る場合はある
ブラウザが成功と認識しても実は失敗してたなんてことは普通にある話だ
ダウンロードしたファイルが開けなかった
でも取り直したら開けたなんてこと経験したことないか？
最近はブラウザの品質が良いからそう頻繁に起こることでもないがそういうことは原理的にありえるんだ
2020/01/12(日) 16:35:47.13ID:BtWuREj/
>>799
質問者は「今日のダウンロードが成功したかどうかを判定する方法」を知りたがってる
ファイルが昨日ダウンロードしたものかどうかは聞いてない
今日のダウンロードが成功したことがわかればそのファイルが昨日のものではないことは明らかなのだからそれを聞く意味がない
2020/01/12(日) 16:36:13.49ID:bSfOvwvy
> お前の論調は余計な要件を増やすなだろ

だから違うって。日本語理解しろよ。
スコープとズレた箇所でいきなり「セキュリティ意識が低い」とか頭湧いてるって言ってんだよ。

あと、「HTTPリクエストの失敗要因はネットワークやサーバーサイドだけじゃねえぞ？ 」って違うからな。
なんとなくは理解してるみたいだけど、HTTPステータスコードって基本的には「Webサーバ」が返すインフォメーションだから。

ほかもひどいな。自爆もほどほどに＾＾；
2020/01/12(日) 16:47:38.45ID:yD0L96jY
>>758
こんなんじゃねと考えた

ファイル名に今日の日付が含まれる仕様である場合
→ファイル名チェックをする

ファイル内部の特定のセルなどに今日の日付が含まれる仕様である場合
→特定のセルなどをチェックする

そうでない場合
→どっかに今日の日付を探してそれをチェックする 例えばダウンロードページ（に遷移する前とか）に「○月○日のデータはこちら」みたいな箇所があればそこのhtmlをチェックする
→あるいは目視チェックする 手作業でダウンロードするよりは数倍楽でしょ データの形式とかHPの仕様が変わることもあるから無難でもある
2020/01/12(日) 16:48:25.04ID:BtWuREj/
>>804
ダウンロード失敗の要因にセキュリティ攻撃の可能性もあるのだからそこは当然考慮すべき

サーバーがどんなHTTPステータスコードを返そうがそれ以外にもHTTPリクエストが失敗する要因があるんだよ
だからHTTPステータスコードだけじゃなくHTTPモジュールの返すステータスコード（あるいは例外）を見る必要があるんだよ
あえてステータスコードと一段抽象化して書いたのはそういう理由だ
無知な人はHTTPリクエストの失敗要因はサーバーだけにあると勘違いしてHTTPステータスコードだけ見ればいいやなどと思っちゃうのかもしれんがな
お前さ管理ばっかりでプログラム書いたことないだろう？
2020/01/12(日) 21:13:09.66ID:04cjRg0b
ここRPAのスレだよね?
セキュリティとか関係無いだろ。

そもそもセキュリティ考えなきゃいけないようなもんはRPAで組んじゃいかん。
ブラウザからダウンロードする時のセキュリティと同レベルでOK。
つまり、特別なもんは必要無い。
逆にそれでOKじゃないならRPAじゃ無くて専用のアプリ組んで、それをRPAから呼び出すようにすべきだろ。
2020/01/12(日) 21:18:41.88ID:04cjRg0b
ダウンロード失敗の判定も特別なもんは必要無さそうだ。
帳票というのが何のファイルか分からんけどOffice文書なら、zipだから化けたら開けんだろ。

どっちにしろ、判定なんて状況によりいろんな方法が有るんだから、どうにも特別な方法が必要という状況になってから考えるべきだろ。
2020/01/12(日) 22:23:36.41ID:zPbjC6MN
>>807
それじゃあ何もできないぞ
セキュリティ無視できるタスクなんてめったにない
つうか自動化する以上は事故ったときのリスクも増大するからセキュリティは手作業のときより神経質にならなきゃいかん
2020/01/13(月) 02:27:18.98ID:CdKMm6na
>>809
そんなにセキュリティが大事ならWindows使うのがもうダメ。
というかメジャーOS全てダメだな。
独自OSを開発する必要がある。

それくらいナンセンスだよ。
鉄壁のセキュリティのすぐ横でユ―ザーがメール添付のウィルスファイルダブルクリックしてアホだろう。
2020/01/13(月) 03:26:38.47ID:DzRETjKI
被害妄想レベルのセキュリティ意識ｗ
ローカル端末使っとけよｗｗｗ
2020/01/13(月) 09:21:35.75ID:II7jjoOs
お前らまじでセキュリティ意識低いな
当たり前のようにやるべきことを普通にやれって言ってるだけだぞ？
2020/01/13(月) 10:02:16.92ID:XrlS1QE+
自宅警備しかしてないからそんなセキュリティ意識になるんだよ。
お一人様CSIRTでも作っとけｗ
2020/01/13(月) 10:12:57.47ID:CdKMm6na
>>812
RPAというのは手作業を自動化するようなもの。
手作業で必要なセキュリティ対策で十分。
2020/01/13(月) 10:14:48.22ID:CdKMm6na
セキュリティ意識が低いとかバカ丸出しだ。
そっちの方が低い。

セキュリティが必要ならRPAをやめるべき。
2020/01/13(月) 10:47:53.03ID:8EXCq9RG
>>814
ほんこれ
2020/01/13(月) 10:54:41.70ID:pulMCdUh
>>814
駄目だぞ
人間だと、あっやっちまった、って気付いてすぐに対処に入ることができることでも、プログラム化したらそうはいかない
ループで100回処理するとこにバグやセキュリティ障害があったら、手作業のときより100倍の被害が出てもおかしくない
手作業のときと同じセキュリティレベルじゃ全く足りないんだよ
手作業のときと同じってのは宣伝文句でしかなく、実際にはプログラムと手作業は全くの別物なんだ
作業者の責任能力の違いも大きい
2020/01/13(月) 11:05:53.86ID:nlvLw0Pz
>>817
それはエラー処理の話
セキュリティの話じゃない
2020/01/13(月) 11:10:36.60ID:II7jjoOs
手作業ってのは暗黙知の塊だ
手作業と同じって感覚でやってたら、なにかしら見落としが生じる
手作業とプログラムは違うものだという当たり前の前提に立って、プログラムが処理しやすい、プログラマが間違えにくい方法でロジックを再編しろ
2020/01/13(月) 11:11:11.93ID:II7jjoOs
>>818
セキュリティも同じ
2020/01/13(月) 11:12:30.09ID:CdKMm6na
マウスで2ヵ所クリックするだけのアプリはリスクが低い。
ループとか高度なことをするからリスクが上がる。
RPAでリスクを考えるべきほど高度なことするからおかしくなる。

本当にリスクを考えるべきならRPAを辞めれば良い。
2020/01/13(月) 11:16:07.47ID:CdKMm6na
というか、普通のプログラムでもセキュリティなんて大して考えないけどな。

考えるべき所なら最初からそれ用で揃える筈。
俺ん所にゃそんな発注はそもそも来ない。
2020/01/13(月) 11:24:35.36ID:II7jjoOs
RPAの性質上セキュリティ対策は必要不可欠
外部サービスを含め様々なアプリやサービスにアクセスするから、一般的な手法で開発されるプログラムよりセキュリティ事故を起こしうるポイントが多くなる

またRPAプログラムに与える権限が強すぎる点も問題だ
例えば外部サイトから特定のデータを定期的にダウンロードしたい、という目的のために、その外部サイトのアカウントをプログラムに持たせなければならない
特定のデータダウンロードしたいだけなのに、そのアカウントの全操作権限を渡さなければならないということだ
これはやりたいことに対してリスクが大きすぎる

人間が手作業でやる場合は人間直感と柔軟な対応力、そして責任能力を持ってしてカバーしうる問題だがプログラムではそうはいかない
プログラムには直感も柔軟性も責任能力もない
なのでプログラムは手作業のときよりもより厳重にセキュリティ対策を施さなければならない
2020/01/13(月) 11:44:58.82ID:nlvLw0Pz
>>820
アホなのか？
人手の作業で気付いてなんとかできるなら既にセキュリティズタボロってことだぞw
2020/01/13(月) 11:47:33.01ID:nlvLw0Pz
>>823
だから柔軟性でなんとかなるなんてセキュリティボロボロやん
性善説でなんとかできるならセキュリティなんて要らんよw
2020/01/13(月) 12:01:22.27ID:XrlS1QE+
対策するかしないかはリスク判定してからだぞ。
システム全体のリスク判定できない病は新人が陥るやつだから、さっさと抜け出せｗ
2020/01/13(月) 12:03:13.22ID:IOw3xBOo
>>824>>825
セキュリティに完全はねえよ
可能な限り無いように務めるが起こるときは起こる
そして起きてしまったときの対応力は業務プログラムより人間のほうが遥かに高い
事前に想定しきれなかったことにも対処できるのが手作業の強みだ
2020/01/13(月) 12:20:00.30ID:nlvLw0Pz
>>827
だから起きてからの対応はセキュリティの話じゃねーだろ
起きないようにするのがセキュリティなの
あと起こってからの対応とか言ってるけど余計なことして傷口広げる例なんていくらでもある
2020/01/13(月) 12:34:01.16ID:XrlS1QE+
>>828
おぃおぃ。起きてからの対応決めとくのはセキュリティの重要項目だぞ。
これだから底辺しか見てないヤツは困る。全体を知れ。
2020/01/13(月) 12:47:22.58ID:nlvLw0Pz
>>829
JIS Q 27002（ISO/IEC 27002）にはそんなもんは定義されてないけどなw
お前が言ってるのはインシデント対応
しかも、検出・分析と封じ込め・根絶・復旧の区別もついてない
そもそも手作業だからなんとかなるとか言ってる時点でセキュリティを語るレベルじゃない
2020/01/13(月) 12:54:45.07ID:XrlS1QE+
>>830
ほんと底辺ｗ
2020/01/13(月) 12:58:37.89ID:nlvLw0Pz
JISも知らなくてクヤシーまで読んだw
2020/01/13(月) 13:02:45.72ID:XrlS1QE+
>>831
JIS Q 27002 で組織と責任範囲を設定をして、インシデントに対してのしきい値を設定するまでが、一般的なセキュリティ対応な。
覚えとけｗ
2020/01/13(月) 13:14:42.49ID:nlvLw0Pz
インシデントのしきい値？
ちょっと説明してみ、ソース付きでなw
2020/01/13(月) 13:19:07.91ID:SIUc1M0X
>>828
アホすぎ
てめえは想定しきれなかったセキュリティ事故は起きたら放置すんのかよ
ろくに事後対応に備えず原発推進して被害拡大させた連中と同じだな
2020/01/13(月) 13:22:12.09ID:V4HNq25L
なんちゃら規格って持ち出して偉そうに語る老害って資格コレクターで実際の現場では全然役に立たない無駄な仕事量産マシーンになるのが定番パターンだから困る
2020/01/13(月) 13:24:58.90ID:XrlS1QE+
>>834
CSIRTを知らんやつとこれ以上話すことねぇよｗ
2020/01/13(月) 13:27:04.60ID:nlvLw0Pz
>>835-836
セキュリティ要件とインシデント対応の区別をつけろ
って話な
まあ言い返せなくてクヤシーってことなんだろうけどw
で、君らはインシデントのしきい値と言う謎用語はわかるわけ？
わかるなら説明してよw
2020/01/13(月) 13:27:11.09ID:DzRETjKI
セキュリティくんは細かいこと気にし過ぎて
仕事進められないタイプだね
老害リストラ予備軍＾＾
2020/01/13(月) 13:30:27.31ID:nlvLw0Pz
>>837
セキュリティの話に組織ガーとか
必死にググったんだろうなw
2020/01/13(月) 13:31:23.21ID:oxUV3TeC
事故後の対応を事前に決めれるなら原因もわかってるはずだからそもそも事故が発生しないようにすればいい
事前に予測できなかったものだけが事故として起こる
だから事故が発生した後の柔軟な対応が大事なんだよ
事前に決めれることだけでは全くもって不十分
狡猾で研究熱心なハッカーがどんな攻撃手段を考えてくるか事前になんでも予測できるかって話だよ
2020/01/13(月) 13:32:57.83ID:nlvLw0Pz
>>839
技術者がセキュリティ語るならこの程度の用語を使い分けるのは常識だと思うけどね
まあグダグダのままなんとなくでセキュリティ確保できたーとか思ってる企業もいっぱいあるみたいだけどw
2020/01/13(月) 13:36:28.36ID:nlvLw0Pz
>>841
> 事故後の対応を事前に決めれるなら原因もわかってるはずだからそもそも事故が発生しないようにすればいい
アホなの？
原因はともかくバックアップからリストアする
なんて対応は普通にあるだろ

> だから事故が発生した後の柔軟な対応が大事なんだよ
事前の準備もしてなきゃアタフタするだけだろw
マジでセキュリティ要件とかインシデント対応の区別がついてないんだな
2020/01/13(月) 13:36:38.09ID:DzRETjKI
誰も読まない規格書作りまくって
セキュリティ対策した気になるやついるよねｗ
2020/01/13(月) 13:38:22.90ID:XrlS1QE+
>>842
そｒｙ使い分けるのが常識だわ。
なんでセキュリティの話にインシデント対応が含まれないと思ったんだ？
ISMSなんて、半分組織の話だぞ。

要件のはなししてるときにリスク判定しないとか、セキュリティの話ししてるときに組織な話が出るとにげるとか底辺すぎｗ

何度も言うけど、新人病だからさっさと抜け出さえよ。
2020/01/13(月) 13:40:23.42ID:XrlS1QE+
>>843
> 原因はともかくバックアップからリストアする

そんな対応はセキュアな組織ではしない。
セキュリティ意識低すぎｗｗｗ
2020/01/13(月) 13:41:58.50ID:Dv2NHD6v
>>843
事故を検出した時にバックアップからリストアすることが正しい対応と「事前にわかってる」ならそういうシステムを組めばいい
今は「事前に正解がわからないこと」を論じてる
お前は世界中のハッカーがどんな脆弱性を付いてどんな攻撃をしてどんな被害がでてどんな対処をすればいいか予め全て理解してるのか？そんなことは不可能だ
だから事後対応の柔軟性が求められるんだよ
そんなことは業務プログラムには不可能で必ず人間が手を動かさなければならない
2020/01/13(月) 13:45:48.41ID:Dv2NHD6v
事後対応の柔軟性が重要とは言ったが事前の対応や計画が不要という意味ではないぞ
事前にも力を尽くした上での事後対応の柔軟性が重要ということだ
規格マニアのバカは下手すると今回の事故は規格や計画にないから対応はやらなくていいですとか言い出しかねない
2020/01/13(月) 14:13:41.42ID:CdKMm6na
お前らはRPAを使うな。
ゲラゲラw
2020/01/13(月) 14:19:40.66ID:nlvLw0Pz
>>845
最初の話は>>664辺りな
追い込まれてCSIRTとか言っちゃって引っ込みつかなくなったんだろうけどセキュリティの基本は何を誰からどうやって守るか
2020/01/13(月) 14:21:49.85ID:nlvLw0Pz
>>846
バカにもわかるように例示しただけだぞ
もしかして「原因はともかく」を原因なんて調べないって読んじゃったか？
底辺にはよくある勘違いだがw
2020/01/13(月) 14:24:21.39ID:nlvLw0Pz
>>847-848
だれも事故対応までRPAでやるなんて言ってないけどw
上にも書いたけど「検出・分析と封じ込め・根絶・復旧」の区別ぐらいつくようになってから出直せよ
2020/01/13(月) 14:31:18.65ID:XrlS1QE+
>>851
セキュアな組織では、インシデントに応じて、エスカレーションがなされる。
で、一般的には、原因が不明な状態でとりあえず「バックアップからリストアする 」なんてぬるい判断は責任ある立場のやつほどしない。

「インシデントに対してのしきい値」が理解できないことが原因だから、「CSIRT インシデント 判定」ぐらいでググって、にわか知識でもつけてこいｗ
2020/01/13(月) 14:33:47.38ID:XrlS1QE+
>>850
「何を」の部分の発想がお前は底辺なんだよｗ
2020/01/13(月) 14:42:46.11ID:nlvLw0Pz
>>853
それは状況による
サービス継続が至上命題のシステムもある
で、インシデントしきい値の説明早くしろよ
2020/01/13(月) 14:43:40.12ID:nlvLw0Pz
>>854
バカには理解できないのかw
2020/01/13(月) 14:49:49.99ID:XrlS1QE+
>>855
> サービス継続が至上命題のシステムもある

原因不明だぞ？SQLインジェクションの攻撃余波でデータが吹っ飛んでたりしたら復旧次第、データ抜き放題じゃねぇかｗ

> インシデントしきい値の説明早くしろよ

なんで、ここまでヒント出して理解できないんだ？
https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20151126.pdf
インシデント発生時のフローとして、トリアージや事象の分析における影響範囲のしきい値を予め設定しておくのがCSIRTの基本なんだよ。
2020/01/13(月) 15:04:03.32ID:nlvLw0Pz
>>857
原因わかるまでサービス停止が許されないこともあるし、インシデントの内容にもよるだろ
やばいIPからのアクセスを禁止して運用再開とかいろいろなケースがある
そう言うのを「柔軟な対応力」って言うんだろw

> https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20151126.pdf
しきい値なんて言葉は書かれてないけど？
判断基準はあるけどしきい値なんて簡単な話じゃないだろうし
2020/01/13(月) 15:07:03.15ID:2q6XWWMq
セキュリティでケチつけて荒らしたいだけでしょ 無視が一番
2020/01/13(月) 15:08:37.91ID:XrlS1QE+
>>858
もうぼろぼろだな。ねとけｗ
2020/01/13(月) 15:14:01.09ID:nlvLw0Pz
ぼろぼろでそれしか言えなくなったのかw
可哀想だな
2020/01/13(月) 15:44:11.42ID:XrlS1QE+
>>861
そりゃ掛ける言葉もなくなるわ。
「やばいIPからのアクセスを禁止して運用再開」なんていい出すやつだぜ。会話が成立せんわ。
セキュリティ意識低すぎｗｗｗ

> 判断基準はあるけどしきい値なんて簡単な話じゃないだろうし

しきい値として記述できるレベルの簡単な判断基準に落とし込むんだよ。
特にエスカレーションは、あまり判断しなくて良いように基準を決める。
簡単じゃない部分はエスカレーション先の責任者が判断するような仕組みを作るのがセキュアな組織作りな。
底辺には理解できない範囲なのよ。
2020/01/13(月) 16:09:06.99ID:CdKMm6na
>>862
バ―カw
セキュアな組織作りは既にされている前提だろ。
RPAのレベルなんてそれより下位か同等までだ。
2020/01/13(月) 16:10:06.62ID:CdKMm6na
RPAなんて底辺なんだから無理するな。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況