[過去ﾛｸﾞ] [RPA]PC自動化技術総合スレ[効率化] Part.7 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
815: 2020/01/13(月)10:14 ID:CdKMm6na(3/8) AAS
セキュリティ意識が低いとかバカ丸出しだ。
そっちの方が低い。
セキュリティが必要ならRPAをやめるべき。
816: 2020/01/13(月)10:47 ID:8EXCq9RG(1) AAS
>>814
ほんこれ
817(1): 2020/01/13(月)10:54 ID:pulMCdUh(1) AAS
>>814
駄目だぞ
人間だと、あっやっちまった、って気付いてすぐに対処に入ることができることでも、プログラム化したらそうはいかない
ループで100回処理するとこにバグやセキュリティ障害があったら、手作業のときより100倍の被害が出てもおかしくない
手作業のときと同じセキュリティレベルじゃ全く足りないんだよ
手作業のときと同じってのは宣伝文句でしかなく、実際にはプログラムと手作業は全くの別物なんだ
作業者の責任能力の違いも大きい
818(1): 2020/01/13(月)11:05 ID:nlvLw0Pz(1/26) AAS
>>817
それはエラー処理の話
セキュリティの話じゃない
819: 2020/01/13(月)11:10 ID:II7jjoOs(2/4) AAS
手作業ってのは暗黙知の塊だ
手作業と同じって感覚でやってたら、なにかしら見落としが生じる
手作業とプログラムは違うものだという当たり前の前提に立って、プログラムが処理しやすい、プログラマが間違えにくい方法でロジックを再編しろ
820(1): 2020/01/13(月)11:11 ID:II7jjoOs(3/4) AAS
>>818
セキュリティも同じ
821: 2020/01/13(月)11:12 ID:CdKMm6na(4/8) AAS
マウスで2ヵ所クリックするだけのアプリはリスクが低い。
ループとか高度なことをするからリスクが上がる。
RPAでリスクを考えるべきほど高度なことするからおかしくなる。
本当にリスクを考えるべきならRPAを辞めれば良い。
822: 2020/01/13(月)11:16 ID:CdKMm6na(5/8) AAS
というか、普通のプログラムでもセキュリティなんて大して考えないけどな。
考えるべき所なら最初からそれ用で揃える筈。
俺ん所にゃそんな発注はそもそも来ない。
823(1): 2020/01/13(月)11:24 ID:II7jjoOs(4/4) AAS
RPAの性質上セキュリティ対策は必要不可欠
外部サービスを含め様々なアプリやサービスにアクセスするから、一般的な手法で開発されるプログラムよりセキュリティ事故を起こしうるポイントが多くなる
またRPAプログラムに与える権限が強すぎる点も問題だ
例えば外部サイトから特定のデータを定期的にダウンロードしたい、という目的のために、その外部サイトのアカウントをプログラムに持たせなければならない
特定のデータダウンロードしたいだけなのに、そのアカウントの全操作権限を渡さなければならないということだ
これはやりたいことに対してリスクが大きすぎる
人間が手作業でやる場合は人間直感と柔軟な対応力、そして責任能力を持ってしてカバーしうる問題だがプログラムではそうはいかない
プログラムには直感も柔軟性も責任能力もない
なのでプログラムは手作業のときよりもより厳重にセキュリティ対策を施さなければならない
824(1): 2020/01/13(月)11:44 ID:nlvLw0Pz(2/26) AAS
>>820
アホなのか？
人手の作業で気付いてなんとかできるなら既にセキュリティズタボロってことだぞw
825(1): 2020/01/13(月)11:47 ID:nlvLw0Pz(3/26) AAS
>>823
だから柔軟性でなんとかなるなんてセキュリティボロボロやん
性善説でなんとかできるならセキュリティなんて要らんよw
826: 2020/01/13(月)12:01 ID:XrlS1QE+(2/24) AAS
対策するかしないかはリスク判定してからだぞ。
システム全体のリスク判定できない病は新人が陥るやつだから、さっさと抜け出せｗ
827(1): 2020/01/13(月)12:03 ID:IOw3xBOo(1) AAS
>>824>>825
セキュリティに完全はねえよ
可能な限り無いように務めるが起こるときは起こる
そして起きてしまったときの対応力は業務プログラムより人間のほうが遥かに高い
事前に想定しきれなかったことにも対処できるのが手作業の強みだ
828(2): 2020/01/13(月)12:20 ID:nlvLw0Pz(4/26) AAS
>>827
だから起きてからの対応はセキュリティの話じゃねーだろ
起きないようにするのがセキュリティなの
あと起こってからの対応とか言ってるけど余計なことして傷口広げる例なんていくらでもある
829(1): 2020/01/13(月)12:34 ID:XrlS1QE+(3/24) AAS
>>828
おぃおぃ。起きてからの対応決めとくのはセキュリティの重要項目だぞ。
これだから底辺しか見てないヤツは困る。全体を知れ。
830(1): 2020/01/13(月)12:47 ID:nlvLw0Pz(5/26) AAS
>>829
JIS Q 27002（ISO/IEC 27002）にはそんなもんは定義されてないけどなw
お前が言ってるのはインシデント対応
しかも、検出・分析と封じ込め・根絶・復旧の区別もついてない
そもそも手作業だからなんとかなるとか言ってる時点でセキュリティを語るレベルじゃない
831(1): 2020/01/13(月)12:54 ID:XrlS1QE+(4/24) AAS
>>830
ほんと底辺ｗ
832: 2020/01/13(月)12:58 ID:nlvLw0Pz(6/26) AAS
JISも知らなくてクヤシーまで読んだw
833(1): 2020/01/13(月)13:02 ID:XrlS1QE+(5/24) AAS
>>831
JIS Q 27002 で組織と責任範囲を設定をして、インシデントに対してのしきい値を設定するまでが、一般的なセキュリティ対応な。
覚えとけｗ
834(1): 2020/01/13(月)13:14 ID:nlvLw0Pz(7/26) AAS
インシデントのしきい値？
ちょっと説明してみ、ソース付きでなw
上下前次1-新書関写板覧索設栞歴
あと 168 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.086s