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

1 名前：デフォルトの名無しさん mailto:sage [2019/11/19(火) 20:35:47.34 ID:K8abzL+c.net] 語りましょう 次スレは>>950がたててね 792 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 12:16:04.96 ID:BjDdiYvI.net] こいつやべえな バ　ッ　ク　ア　ッ　プ の話題なのに 大　本　が　壊　れ　た　ら　ダ　メ とか本末転倒すぎて話にならん 大　本　が　壊　れ　た　時　の　話 してんだよバカ 793 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 12:27:06.70 ID:bSfOvwvy.net] >>778 壊れたらどうやって「大元と同じだった」って証明するんだよ。 ばかｗ 794 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 12:37:55.95 ID:/os/mmOS.net] >>779 バカの世界チャンプか？ ダウンロード後に大元と同じことを確かめるにはどうすればいいのか？ってことを議論してんだろが 壊れた後の話にすりかえてんじゃねえよダウンロード直後には大元は生きてる前提だろが スタート地点に戻って質問をよく見直してこい そしてもう帰ってくるな 795 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 12:47:02.01 ID:bSfOvwvy.net] >>780 あれ？問題すり替わってるぞ。 問題だったのは、 > 銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？ > 「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」 という判定をどうすればいいか、思いつかない で、別に大元と同じことを確かめたいって要件はない。 その要件はお前がいい出しただけで、俺がリスク判定的に「無駄」って指摘したんだけど？ もう一度言おうｗ「日本語読め」ｗ 796 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 12:57:43.04 ID:/os/mmOS.net] >>781 はぁやれやれ ダウンロードに成功したってことは大元と同じデータが手元にあるって事だ つまりこれはローカルとリモートのデータの同値性をいかにして担保するかという問題なんだよ てめえが関わると要件漏れで大惨事まっしぐらだな 797 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 13:10:11.02 ID:bSfOvwvy.net] >>782 > つまりこれはローカルとリモートのデータの同値性をいかにして担保するかという問題なんだよ だから、それ言い出したのお前だし、意味がないって言ってるんだけど。 大元がぶっ壊れたら無駄になる程度のデータなら、別にダウンロード元の厳密な検証とか必要ないし 計算が合わないとかのシステム上の不整合で検証するのがまっとうだろ。 ダウンロード時のセキュリティとか、ブラウザレベルの実装で問題ない。 なんか、本気で言ってるっぽいからカワイソウになってきたわ。 798 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 13:30:43.81 ID:/os/mmOS.net] >>783 厳密な検証が必要ないなら迷うところなんてないんだから質問しねえわ つかブラウザでセキュリティ十分とか言ってるなら本気でアホだぞ 799 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 13:44:00.39 ID:bSfOvwvy.net] >>784 質問はコレ > 銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？ > 「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」 という判定をどうすればいいか、思いつかない お前、全然ずれたこと言ってんのよ。 > つかブラウザでセキュリティ十分とか言ってるなら本気でアホだぞ ブラウザレベルって言うよりももっと限定的に「使用する証明書選択をただしくね」ぐらいだな。 セキュリティ意識すればするほど要件的に無駄が分かってくる。 それよりも、>>773 とかをどう拾うとかのほうが考察としては面白い。 多分、ログイン後の「需要なお知らせ」系の処理だと思うけど、しんどそう。 800 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 13:57:39.24 ID:/os/mmOS.net] >>785 ずれてんのはお前な セキュリティを意識してないから要件漏れだらけだ 773は今は別の問題で誰も議論してない 801 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 14:00:43.14 ID:bSfOvwvy.net] >>786 俺の言ってること、理解できないんでしょ？ もう君出てこなくていいよｗ それより >>773 を深めたほうがスレ的に面白い。 突発的に出てきそうなお知らせって、みんなどうやって拾おうとしてる？ 802 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 14:23:22.55 ID:BrY9V3ck.net] >>787 そっくり返すわ お前も出てくんな 803 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 14:36:27.29 ID:bSfOvwvy.net] >>788 だって君、質問も理解できてないし、リスク分析もできないし、勝手に条件追加するし、勝手に要件も追加しようとする。 邪魔なだけじゃん。 プロジェクト炎上屋さんでしょ。いらんわｗ 804 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 14:39:42.55 ID:wzOQ6goX.net] >>789 だって君、質問も理解できてないし、リスク分析もできないし、隠れた条件見逃すし、要件お漏らしするし 邪魔なだけじゃん プロジェクト炎上屋さんでしょ。要らんわ 805 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 14:54:13.91 ID:bSfOvwvy.net] >>790 ナンだよ隠れた条件って。勝手に付け加えるなｗ 質問者からそんな追加条件ヒアリングできてないぞ。 お前、ずーと一人でスコープがずれてんのよ。 だから会話にならんし、人の言うことが理解できない。 そろそろ学習しろ。何回同じこと繰り返してるの？ 806 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 15:06:00.25 ID:khQ0wJGz.net] >>791 んなこと言ってるから本来必要な要件をお漏らししてあとで大事故に繋がるんだよ 相手が言ったことだけを鵜呑みにするな それは何も考えないバカのやりかただ 807 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 15:18:55.74 ID:bSfOvwvy.net] >>792 > 相手が言ったことだけを鵜呑みにするな ちがうぞ。必要なら相手に提案して「ヒアリング」するんだよ。 で、エビデンスを残す。 勝手に追加するのはプロジェクトとして最悪の結果を残すし、そんなやつはプロジェクトにいらない。 だれも必要としていない提案すらまともでない内容を勝手に追加するな。 今回だと、 > 銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？ > 「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」 という判定をどうすればいいか、思いつかない に対して、なぜ、 > ステータスコードなんてのは、通信中に明らかなエラーはなかったね、程度の認識でいい ステータスOKならそこから更に、中間者攻撃がなかったか、データ破損がなかったか、等のより精度の高いチェックをするのが当たり前だ みたいな話が出る？ そもそもお前の言ってるステータスコードが「HTTPステータスコード」なら、このコメントすら間違ってるんだけど？ 808 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 15:40:20.21 ID:BtWuREj/.net] >>793 つうか前から思ってたがここはプロジェクトじゃねえぞ間抜け ヒアリングしてないのはお前も同じ 質問者の発言は「ダウンロード成功したかどうか判断方法がわからない」だけだ ダウンロード成功の定義が定まってない以上は過不足を論じることはできない お前は余計な要件を追加するなというがそれが余計かどうかもわからん 俺が言うようにお前が必要な要件を勝手に無視してるかもしれん リアルなプロジェクトでない掲示板ではよくあるシチュエーションだが質問者が議論に参加する気がない場合は平均的なシチュエーションを想定して論じるしかない となると答えは信頼できるハッシュ値との比較が妥当なところだろとなるわけだ HTTPステータスコードと誰かが言ったか？ 809 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 15:45:24.57 ID:BtWuREj/.net] つうかステータスコードをHTTPステータスコードと読み替えても特に問題ないだろそこ 810 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 15:55:29.27 ID:bSfOvwvy.net] >>792 > ヒアリングしてないのはお前も同じ そうそう。。だから提示された内容に対してのみコメントするようにしている。 だから余計な追加はしてない。 > ダウンロード成功の定義が定まってない以上は過不足を論じることはできない そうそう。過不足を論じるな。 > リアルなプロジェクトでない掲示板ではよくあるシチュエーションだが質問者が議論に参加する気がない場合は平均的なシチュエーションを想定して論じるしかない そうそう。分かってんじゃん。 ただ、平均が何かはシュチュエーションによる。 わからない場合は、「提示された内容で」進めるのがズレないコツ。 この場合は、「銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたい」っていうよくあるダウンロード案件。 > HTTPステータスコードと誰かが言ったか？ ナンのステータスコードを指したんだ？(これがヒアリング) > 信頼できるハッシュ値との比較が妥当なところだろとなるわけだ ならねーよばかｗ なんでそこで飛ぶｗ ところで、 > 今は署名もハッシュもない状況を議論してんだよ そんな条件は、だ・れ・が・決めた？ 811 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:06:16.36 ID:gAizTjEJ.net] すげえ長々とやり合ってる所申し訳ない >753、>>758の話だけ見ると >「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」 単純にファイルダウンロードに成功したかどうかだけなら とりあえず日付でファイル名作って存在チェックだけやればええんやないの？ セキュリティ面の話は 812 名前：その次のステップじゃ？ [] [ここ壊れてます] 813 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:11:41.42 ID:gAizTjEJ.net] ぶっちゃけ要件なんて後出しでコロコロ変わるんだから ・ツールでやりたい事（現行業務のヒアリング、自動化のフロー/処理の流れの策定） ・その上で必要なエラーチェック処理（ファイル存在チェック、アクセス可否チェック、整合性チェック等など） 正直、やりたい事も分からずに互いの妄想だけで殴り合ってるのは不毛すぎるわ 814 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:14:25.30 ID:bSfOvwvy.net] >>797 これ、今日ダウンロードしたファイルはホントに今日の作成のモノなの？って疑問だから、ダウンロード日の比較だとちょっとまずい。(ダウンロードファイル名に作成日付が入っていればいいけど。) で、前日ファイルと当日ファイルの内容比較なら、ハッシュの比較でいいんでは？ってのがコメントとしてついてる。 意識高い君がズレたこと言ってるから、ミスリードになってるけど、元の文脈はそんな感じ。 815 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:21:20.58 ID:gAizTjEJ.net] >>799 ああ、そういう流れでハッシュ値比較が出たのか 個人的にはファイルのタイムスタンプで見たいかな あれなら作成日時とれるし 816 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:22:25.75 ID:BtWuREj/.net] >>796 提示された内容に対してのみコメントとかよく言えたもんだ お前の論調は余計な要件を増やすなだろ 先程も言ったが要件が定まってないのに要件を増やすなとは言うことはできない つまりお前も脳内で勝手に定めた要件を基にして発言しているんだよ それは提示された内容ではない 提示された内容は「銀行サイトからダウンロードする際にダウンロード成功を判定する方法」だ 何を持ってダウンロード成功とみなすかは未定義な HTTPモジュールの返すステータスあるいは投げる例外だよ バカでもわかると思うがHTTPリクエストの失敗要因はネットワークやサーバーサイドだけじゃねえぞ？ 妥当だぞ セキュリティが絡むファイルのダウンロードを必要とする場面ではハッシュ値の比較はポピュラーな解決策だ コストと安定性と精度の観点から見てバランスがいいんだよ もちろんサービス側がハッシュ値を公開してる前提だが デジタル署名もないハッシュ値も無い場合に比較的有効な確認方法は形式チェックと複数回ダウンロードだが 形式チェックはエラーが小さいと意外とチェックに引っかからない場合がある 複数回ダウンロードはファイルダウンロードの通信経路が保護されてる前提だがエラー検出の精度はかなり高い 817 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:26:38.27 ID:BtWuREj/.net] >>797 ファイルが存在するかだけじゃ駄目だ ダウンロードに失敗してもファイルが残る場合はある ブラウザが成功と認識しても実は失敗してたなんてことは普通にある話だ ダウンロードしたファイルが開けなかった でも取り直したら開けたなんてこと経験したことないか？ 最近はブラウザの品質が良いからそう頻繁に起こることでもないがそういうことは原理的にありえるんだ 818 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:35:47.13 ID:BtWuREj/.net] >>799 質問者は「今日のダウンロードが成功したかどうかを判定する方法」を知りたがってる ファイルが昨日ダウンロードしたものかどうかは聞いてない 今日のダウンロードが成功したことがわかればそのファイルが昨日のものではないことは明らかなのだからそれを聞く意味がない 819 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:36:13.49 ID:bSfOvwvy.net] > お前の論調は余計な要件を増やすなだろ だから違うって。日本語理解しろよ。 スコープとズレた箇所でいきなり「セキュリティ意識が低い」とか頭湧いてるって言ってんだよ。 あと、「HTTPリクエストの失敗要因はネットワークやサーバーサイドだけじゃねえぞ？ 」って違うからな。 なんとなくは理解してるみたいだけど、HTTPステータスコードって基本的には「Webサーバ」が返すインフォメーションだから。 ほかもひどいな。自爆もほどほどに＾＾； 820 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:47:38.45 ID:yD0L96jY.net] >>758 こんなんじゃねと考えた ファイル名に今日の日付が含まれる仕様である場合 →ファイル名チェックをする ファイル内部の特定のセルなどに今日の日付が含まれる仕様である場合 →特定のセルなどをチェックする そうでない場合 →どっかに今日の日付を探してそれをチェックする 例えばダウンロードページ（に遷移する前とか）に「○月○日のデータはこちら」みたいな箇所があればそこのhtmlをチェックする →あるいは目視チェックする 手作業でダウンロードするよりは数倍楽でしょ データの形式とかHPの仕様が変わることもあるから無難でもある 821 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 16:48:25.04 ID:BtWuREj/.net] >>804 ダウンロード失敗の要因にセキュリティ攻撃の可能性もあるのだからそこは当然考慮すべき サーバーがどんなHTTPステータスコードを返そうがそれ以外にもHTTPリクエストが失敗する要因があるんだよ だからHTTPステータスコードだけじゃなくHTTPモジュールの返すステータスコード（あるいは例外）を見る必要があるんだよ あえてステータスコードと一段抽象化して書いたのはそういう理由だ 無知な人はHTTPリクエストの失敗要因はサーバーだけにあると勘違いしてHTTPステータスコードだけ見ればいいやなどと思っちゃうのかもしれんがな お前さ管理ばっかりでプログラム書いたことないだろう？ 822 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 21:13:09.66 ID:04cjRg0b.net] ここRPAのスレだよね? セキュリティとか関係無いだろ。 そもそもセキュリティ考えなきゃいけないようなもんはRPAで組んじゃいかん。 ブラウザからダウンロードする時のセキュリティと同レベルでOK。 つまり、特別なもんは必要無い。 逆にそれでOKじゃないならRPAじゃ無くて専用のアプリ組んで、それをRPAから呼び出すようにすべきだろ。 823 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 21:18:41.88 ID:04cjRg0b.net] ダウンロード失敗の判定も特別なもんは必要無さそうだ。 帳票というのが何のファイルか分からんけどOffice文書なら、zipだから化けたら開けんだろ。 どっちにしろ、判定なんて状況によりいろんな方法が有るんだから、どうにも特別な方法が必要という状況になってから考えるべきだろ。 824 名前：デフォルトの名無しさん mailto:sage [2020/01/12(日) 22:23:36.41 ID:zPbjC6MN.net] >>807 それじゃあ何もできないぞ セキュリティ無視できるタスクなんてめったにない つうか自動化する以上は事故ったときのリスクも増大するからセキュリティは手作業のときより神経質にならなきゃいかん 825 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 02:27:18.98 ID:CdKMm6na.net] >>809 そんなにセキュリティが大事ならWindows使うのがもうダメ。 というかメジャーOS全てダメだな。 独自OSを開発する必要がある。 それくらいナンセンスだよ。 鉄壁のセキュリティのすぐ横でユ―ザーがメール添付のウィルスファイルダブルクリックしてアホだろう。 826 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 03:26:38.47 ID:DzRETjKI.net] 被害妄想レベルのセキュリティ意識ｗ ローカル端末使っとけよｗｗｗ 827 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 09:21:35.75 ID:II7jjoOs.net] お前らまじでセキュリティ意識低いな 当たり前のようにやるべきことを普通にやれって言ってるだけだぞ？ 828 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 10:02:16.92 ID:XrlS1QE+.net] 自宅警備しかしてないからそんなセキュリティ意識になるんだよ。 お一人様CSIRTでも作っとけｗ 829 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 10:12:57.47 ID:CdKMm6na.net] >>812 RPAというのは手作業を自動化するようなもの。 手作業で必要なセキュリティ対策で十分。 830 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 10:14:48.22 ID:CdKMm6na.net] セキュリティ意識が低いとかバカ丸出しだ。 そっちの方が低い。 セキュリティが必要ならRPAをやめるべき。 831 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 10:47:53.03 ID:8EXCq9RG.net] >>814 ほんこれ 832 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 10:54:41.70 ID:pulMCdUh.net] >>814 駄目だぞ 人間だと、あっやっちまった、って気付いてすぐに対処に入ることができることでも、プログラム化したらそうはいかない ループで100回処理するとこにバグやセキュリティ障害があったら、手作業のときより100倍の被害が出てもおかしくない 手作業のときと同じセキュリティレベルじゃ全く足りないんだよ 手作業のときと同じってのは宣伝文句でしかなく、実際にはプログラムと手作業は全くの別物なんだ 作業者の責任能力の違いも大きい 833 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:05:53.86 ID:nlvLw0Pz.net] >>817 それはエラー処理の話 セキュリティの話じゃない 834 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:10:36.60 ID:II7jjoOs.net] 手作業ってのは暗黙知の塊だ 手作業と同じって感覚でやってたら、なにかしら見落としが生じる 手作業とプログラムは違うものだという当たり前の前提に立って、プログラムが処理しやすい、プログラマが間違えにくい方法でロジックを再編しろ 835 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:11:11.93 ID:II7jjoOs.net] >>818 セキュリティも同じ 836 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:12:30.09 ID:CdKMm6na.net] マウスで2ヵ所クリックするだけのアプリはリスクが低い。 ループとか高度なことをするからリスクが上がる。 RPAでリスクを考えるべきほど高度なことするからおかしくなる。 本当にリスクを考えるべきならRPAを辞めれば良い。 837 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:16:07.47 ID:CdKMm6na.net] というか、普通のプログラムでもセキュリティなんて大して考えないけどな。 考えるべき所なら最初からそれ用で揃える筈。 俺ん所にゃそんな発注はそもそも来ない。 838 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:24:35.36 ID:II7jjoOs.net] RPAの性質上セキュリティ対策は必要不可欠 外部サービスを含め様々なアプリやサービスにアクセスするから、一般的な手法で開発されるプログラムよりセキュリティ事故を起こしうるポイントが多くなる またRPAプログラムに与える権限が強すぎる点も問題だ 例えば外部サイトから特定のデータを定期的にダウンロードしたい、という目的のために、その外部サイトのアカウントをプログラムに持たせなければならない 特定のデータダウンロードしたいだけなのに、そのアカウントの全操作権限を渡さなければならないということだ これはやりたいことに対してリスクが大きすぎる 人間が手作業でやる場合は人間直感と柔軟な対応力、そして責任能力を持ってしてカバーしうる問題だがプログラムではそうはいかない プログラムには直感も柔軟性も責任能力もない なのでプログラムは手作業のときよりもより厳重にセキュリティ対策を施さなければならない 839 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:44:58.82 ID:nlvLw0Pz.net] >>820 アホなのか？ 人手の作業で気付いてなんとかできるなら既にセキュリティズタボロってことだぞw 840 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 11:47:33.01 ID:nlvLw0Pz.net] >>823 だから柔軟性でなんとかなるなんてセキュリティボロボロやん 性善説でなんとかできるならセキュリティなんて要らんよw 841 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 12:01:22.27 ID:XrlS1QE+.net] 対策するかしないかはリスク判定してからだぞ。 システム全体のリスク判定できない病は新人が陥るやつだから、さっさと抜け出せｗ 842 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 12:03:13.22 ID:IOw3xBOo.net] >>824>>825 セキュリティに完全はねえよ 可能な限り無いように務めるが起こるときは起こる そして起きてしまったときの対応力は業務プログラムより人間のほうが遥かに高い 事前に想定しきれなかったことにも対処できるのが手作業の強みだ 843 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 12:20:00.30 ID:nlvLw0Pz.net] >>827 だから起きてからの対応はセキュリティの話じゃねーだろ 起きないようにするのがセキュリティなの あと起こってからの対応とか言ってるけど余計なことして傷口広げる例なんていくらでもある 844 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 12:34:01.16 ID:XrlS1QE+.net] >>828 おぃおぃ。起きてからの対応決めとくのはセキュリティの重要項目だぞ。 これだから底辺しか見てないヤツは困る。全体を知れ。 845 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 12:47:22.58 ID:nlvLw0Pz.net] >>829 JIS Q 27002（ISO/IEC 27002）にはそんなもんは定義されてないけどなw お前が言ってるのはインシデント対応 しかも、検出・分析と封じ込め・根絶・復旧の区別もついてない そもそも手作業だからなんとかなるとか言ってる時点でセキュリティを語るレベルじゃない 846 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 12:54:45.07 ID:XrlS1QE+.net] >>830 ほんと底辺ｗ 847 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 12:58:37.89 ID:nlvLw0Pz.net] JISも知らなくてクヤシーまで読んだw 848 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:02:45.72 ID:XrlS1QE+.net] >>831 JIS Q 27002 で組織と責任範囲を設定をして、インシデントに対してのしきい値を設定するまでが、一般的なセキュリティ対応な。 覚えとけｗ 849 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:14:42.49 ID:nlvLw0Pz.net] インシデントのしきい値？ ちょっと説明してみ、ソース付きでなw 850 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:19:07.91 ID:SIUc1M0X.net] >>828 アホすぎ てめえは想定しきれなかったセキュリティ事故は起きたら放置すんのかよ ろくに事後対応に備えず原発推進して被害拡大させた連中と同じだな 851 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:22:12.09 ID:V4HNq25L.net] なんちゃら規格って持ち出して偉そうに語る老害って資格コレクターで実際の現場では全然役に立たない無駄な仕事量産マシーンになるのが定番パターンだから困る 852 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:24:58.90 ID:XrlS1QE+.net] >>834 CSIRTを知らんやつとこれ以上話すことねぇよｗ 853 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:27:04.60 ID:nlvLw0Pz.net] >>835-836 セキュリティ要件とインシデント対応の区別をつけろ って話な まあ言い返せなくてクヤシーってことなんだろうけどw で、君らはインシデントのしきい値と言う謎用語はわかるわけ？ わかるなら説明してよw 854 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:27:11.09 ID:DzRETjKI.net] セキュリティくんは細かいこと気にし過ぎて 仕事進められないタイプだね 老害リストラ予備軍＾＾ 855 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:30:27.31 ID:nlvLw0Pz.net] >>837 セキュリティの話に組織ガーとか 必死にググったんだろうなw 856 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:31:23.21 ID:oxUV3TeC.net] 事故後の対応を事前に決めれるなら原因もわかってるはずだからそもそも事故が発生しないようにすればいい 事前に予測できなかったものだけが事故として起こる だから事故が発生した後の柔軟な対応が大事なんだよ 事前に決めれることだけでは全くもって不十分 狡猾で研究熱心なハッカーがどんな攻撃手段を考えてくるか事前になんでも予測できるかって話だよ 857 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:32:57.83 ID:nlvLw0Pz.net] >>839 技術者がセキュリティ語るならこの程度の用語を使い分けるのは常識だと思うけどね まあグダグダのままなんとなくでセキュリティ確保できたーとか思ってる企業もいっぱいあるみたいだけどw 858 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:36:28.36 ID:nlvLw0Pz.net] >>841 > 事故後の対応を事前に決めれるなら原因もわかってるはずだからそもそも事故が発生しないようにすればいい アホなの？ 原因はともかくバックアップからリストアする なんて対応は普通にあるだろ > だから事故が発生した後の柔軟な対応が大事なんだよ 事前の準備もしてなきゃアタフタするだけだろw マジでセキュリティ要件とかインシデント対応の区別がついてないんだな 859 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:36:38.09 ID:DzRETjKI.net] 誰も読まない規格書作りまくって セキュリティ対策した気になるやついるよねｗ 860 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:38:22.90 ID:XrlS1QE+.net] >>842 そｒｙ使い分けるのが常識だわ。 なんでセキュリティの話にインシデント対応が含まれないと思ったんだ？ ISMSなんて、半分組織の話だぞ。 要件のはなししてるときにリスク判定しないとか、セキュリティの話ししてるときに組織な話が出るとにげるとか底辺すぎｗ 何度も言うけど、新人病だからさっさと抜け出さえよ。 861 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:40:23.42 ID:XrlS1QE+.net] >>843 > 原因はともかくバックアップからリストアする そんな対応はセキュアな組織ではしない。 セキュリティ意識低すぎｗｗｗ 862 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:41:58.50 ID:Dv2NHD6v.net] >>843 事故を検出した時にバックアップからリストアすることが正しい対応と「事前にわかってる」ならそういうシステムを組めばいい 今は「事前に正解がわからないこと」を論じてる お前は世界中のハッカーがどんな脆弱性を付いてどんな攻撃をしてどんな被害がでてどんな対処をすればいいか予め全て理解してるのか？そんなことは不可能だ だから事後対応の柔軟性� 863 名前：ｪ求められるんだよ そんなことは業務プログラムには不可能で必ず人間が手を動かさなければならない [] [ここ壊れてます] 864 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 13:45:48.41 ID:Dv2NHD6v.net] 事後対応の柔軟性が重要とは言ったが事前の対応や計画が不要という意味ではないぞ 事前にも力を尽くした上での事後対応の柔軟性が重要ということだ 規格マニアのバカは下手すると今回の事故は規格や計画にないから対応はやらなくていいですとか言い出しかねない 865 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:13:41.42 ID:CdKMm6na.net] お前らはRPAを使うな。 ゲラゲラw 866 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:19:40.66 ID:nlvLw0Pz.net] >>845 最初の話は>>664辺りな 追い込まれてCSIRTとか言っちゃって引っ込みつかなくなったんだろうけどセキュリティの基本は何を誰からどうやって守るか 867 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:21:49.85 ID:nlvLw0Pz.net] >>846 バカにもわかるように例示しただけだぞ もしかして「原因はともかく」を原因なんて調べないって読んじゃったか？ 底辺にはよくある勘違いだがw 868 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:24:21.39 ID:nlvLw0Pz.net] >>847-848 だれも事故対応までRPAでやるなんて言ってないけどw 上にも書いたけど「検出・分析と封じ込め・根絶・復旧」の区別ぐらいつくようになってから出直せよ 869 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:31:18.65 ID:XrlS1QE+.net] >>851 セキュアな組織では、インシデントに応じて、エスカレーションがなされる。 で、一般的には、原因が不明な状態でとりあえず「バックアップからリストアする 」なんてぬるい判断は責任ある立場のやつほどしない。 「インシデントに対してのしきい値」が理解できないことが原因だから、「CSIRT インシデント 判定」ぐらいでググって、にわか知識でもつけてこいｗ 870 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:33:47.38 ID:XrlS1QE+.net] >>850 「何を」の部分の発想がお前は底辺なんだよｗ 871 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:42:46.11 ID:nlvLw0Pz.net] >>853 それは状況による サービス継続が至上命題のシステムもある で、インシデントしきい値の説明早くしろよ 872 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:43:40.12 ID:nlvLw0Pz.net] >>854 バカには理解できないのかw 873 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 14:49:49.99 ID:XrlS1QE+.net] >>855 > サービス継続が至上命題のシステムもある 原因不明だぞ？SQLインジェクションの攻撃余波でデータが吹っ飛んでたりしたら復旧次第、データ抜き放題じゃねぇかｗ > インシデントしきい値の説明早くしろよ なんで、ここまでヒント出して理解できないんだ？ https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20151126.pdf インシデント発生時のフローとして、トリアージや事象の分析における影響範囲のしきい値を予め設定しておくのがCSIRTの基本なんだよ。 874 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 15:04:03.32 ID:nlvLw0Pz.net] >>857 原因わかるまでサービス停止が許されないこともあるし、インシデントの内容にもよるだろ やばいIPからのアクセスを禁止して運用再開とかいろいろなケースがある そう言うのを「柔軟な対応力」って言うんだろw > https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20151126.pdf しきい値なんて言葉は書かれてないけど？ 判断基準はあるけどしきい値なんて簡単な話じゃないだろうし 875 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 15:07:03.15 ID:2q6XWWMq.net] セキュリティでケチつけて荒らしたいだけでしょ 無視が一番 876 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 15:08:37.91 ID:XrlS1QE+.net] >>858 もうぼろぼろだな。ねとけｗ 877 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 15:14:01.09 ID:nlvLw0Pz.net] ぼろぼろでそれしか言えなくなったのかw 可哀想だな 878 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 15:44:11.42 ID:XrlS1QE+.net] >>861 そりゃ掛ける言葉もなくなるわ。 「やばいIPからのアクセスを禁止して運用再開」なんていい出すやつだぜ。会話が成立せんわ。 セキュリティ意識低すぎｗｗｗ > 判断基準はあるけどしきい値なんて簡単な話じゃないだろうし しきい値として記述できるレベルの簡単な判断基準に落とし込むんだよ。 特にエスカレーションは、あまり判断しなくて良いように基準を決める。 簡単じゃない部分はエスカレーション先の責任者が判断するような仕組みを作るのがセキュアな組織作りな。 底辺には理解できない範囲なのよ。 879 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 16:09:06.99 ID:CdKMm6na.net] >>862 バ―カw セキュアな組織作りは既にされている前提だろ。 RPAのレベルなんてそれより下位か同等までだ。 880 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 16:10:06.62 ID:CdKMm6na.net] RPAなんて底辺なんだから無理するな。 881 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 17:19:33.65 ID:nlvLw0Pz.net] >>862 > 「やばいIPからのアクセスを禁止して運用再開」なんていい出すやつだぜ。 そういう対応もあるって話な てか、もうそういう所にしか突っ込めなくなったのかよ > セキュリティ意識低すぎｗｗｗ だからセキュリティじゃなくてインシデント対応な > しきい値として記述できるレベルの簡単な判断基準に落とし込むんだよ。 値にできる項目もあるだろうけどすべてじゃないよな？ セキュリティ分野でインシデントに対してのしきい値なんて言うアホな用語使う奴見たことないわ > 底辺には理解できない範囲なのよ。 無理して自爆してるお前が言うなよw 882 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 17:34:07.36 ID:XrlS1QE+.net] >>865 もうぼろぼろだな。ねとけｗ 883 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 17:53:54.19 ID:1q8+/eQn.net] >>866 >>861 バカループ乙w 884 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 18:25:02.13 ID:XrlS1QE+.net] うちの1年生でも分かる言葉で説明してやっても追いつけないし、「インシデント対応はセキュリティじゃない」とか、「原因はともかくバックアップからリストアする」とか、認識がズレまくってるやつとこれ以上続けてもしょうがないからなぁ。 知らない言葉がいっぱいあるって正直に言うところは好感持てたぞ。 ググっとけ。 あと、がんばってイキロｗ 885 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 19:41:57.50 ID:nlvLw0Pz.net] インシデントに対してのしきい値なんて言う謎の言葉で価値誇られてもなぁw 判断基準を作ったことあればしきい値なんて言う単純なもので済むはずがないことぐらいわかりそうなもんだけどググることしかできない彼にはわからないんだろうな 886 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 19:51:01.01 ID:N+zCCrTG.net] しきい値は草はえるｗ 887 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 21:52:16.56 ID:XrlS1QE+.net] >>869 スレチなんだけどなぁ。。。ｗ インシデント対応の初動は、多くの場合運用チームに任せられて、インシデントの監視は「異常値の発生」がトリガーになる。 オペレータが切り分けを実施するので、運用手順には「しきい値」を明確にした上で、インシデントを定義する。 例えばDDoSを定義するのであれば「回線の80%以上を占める通信が10分間続いた」みたいに客観的に観測できる内容にできるだけ落とし込んで置くことが必要。 実務では、この時点で、インシデントに重要度と影響範囲の判定がなされ、エスカレーション先が決定する。 しきい値って言葉が使われるのは、主に運用チームを相手に定義書を作成するから。 ごく普通の運用定義の風景なんだけど、理解できた？ 888 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 22:15:09.23 ID:BvowWoiX.net] めちゃめちゃスレ進んでて草 889 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 22:24:55.71 ID:nlvLw0Pz.net] 判定基準はしきい値「だけじゃない」って前にも書いたんだけどねぇ… そもそも>>871に書いてあるのは検出基準であってインシデント対応じゃないし DDoSで通信量とかDDoSがなにものかもわかってないみたいだし スレチという以前にぼろぼろすぎるだろw 890 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 22:27:41.03 ID:Zf0H2zIq.net] 結局事前に定めた基準を満たさないならなんの対策もしないんだろ でハッカーはそこを付いてくる 意味ねー 891 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 22:38:25.54 ID:XrlS1QE+.net] >>873 > 判定基準はしきい値「だけじゃない」って前にも書いたんだけどねぇ… > そもそも>>871に書いてあるのは検出基準であってインシデント対応じゃないし インシデント対応の初動が検出なのは当たり前だろ。 スグ話ずらすなぁ。 お前はインシデントのしきい値の意味が知りたかったんだろ？ 理解できたの？ それともまだ理解できない？ > DDoSで通信量とかDDoSがなにものかもわかってないみたいだし DDoS調べてみ。食い尽くされるリソースの一つに回線帯域があるからｗ 892 名前：デフォルトの名無しさん mailto:sage [2020/01/13(月) 22:41:32.65 ID:N9RUr4Lo.net] 3人くらいあぼーんしたら読みやすくなった

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef