X

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

■ このスレッドは過去ログ倉庫に格納されています
2019/11/19(火) 20:35:47.34ID:K8abzL+c
語りましょう
次スレは>>950がたててね
734デフォルトの名無しさん
垢版 |
2020/01/08(水) 01:57:38.47ID:+v9vydRU
>>732
UPは上場ゴールだからこれからもだまして儲けようとしてるんだろ。日本は重要な金づる。
それに比べて既に上場してるBPは偉いよな。客をだまそうとはしてない。
2020/01/08(水) 02:13:53.02ID:C54+Nfg4
BPはユーザーいないな…
2020/01/09(木) 08:20:48.13ID:mOBTP28Q
AI・RPAでコールセンター業務を完全自動化　ドコモとNTTデータが4月以降に提供
https://www.itmedia.co.jp/news/articles/2001/07/news124.html

＞AIは、テキストの読み上げ機能などを備えたAmazon Connectと連携し、電話をかける／受ける作業と、顧客との音声通話を担当する。
＞それに伴って発生する、データ入力などの事務作業をRPAが担う。
2020/01/09(木) 08:35:52.46ID:xgZeL5N0
>>736
NTTデータで開発すれば盤石だと思ったんだろうが。

昨年暮れの自治体クラウドの住民票システム停止から始まって、国税庁システム停止までの事故3件。
これ全部NTTデータ謹製だからなw
ちなみにまだ全面復旧してないと言うていたらく。

昔の実力はもう無いみたい。
下請け丸投げが根付いてしまい、高価格調達に対応しきれずに自己崩壊中らしいから。
2020/01/09(木) 09:07:30.64ID:cmMsCSzT
>>736
データ入力部分は普通にプログラミングしたほうがいいな
2020/01/09(木) 12:43:12.71ID:C87+dDrE
>>737
セブンペイもNTTデータだぜ
高学歴揃えておけば客はどんなゴミでも受け入れるからマジIT楽勝

そういやみずほ銀行のみずほ総研も日本ITの超エリート集団だったな
2020/01/09(木) 17:59:13.20ID:gratcVb8
>>739
つか基幹はNRI、フェイルオーバークラスタはNEC直だから。
常識でしょw

NRIとNTTDは協業はやらんから。

ちなみにセブンペイアプリは小さなソフトハウスな。
アプリなんざNRIはやらないし、丁合い掛けられても出来ないからw
2020/01/09(木) 18:04:24.41ID:+jI2eI6C
SIer主導の開発方式はこのまま変わらないんだろうか
742デフォルトの名無しさん
垢版 |
2020/01/09(木) 19:34:18.50ID:mh+1cp2X
RPAの次のバズワードはDXでしょうか？
日経コンピュータも現金だね。
2020/01/09(木) 19:38:02.38ID:C87+dDrE
次にバズるのは量子コンピュータでしょ
2020/01/09(木) 20:47:28.25ID:iIXgoWH7
量子コンピュータはライブラリ化が必須だろうな。
一般プログラマに量子プログラミングなんて無理だからな。
2020/01/09(木) 23:12:22.20ID:NaQHxKOV
受け売りだけど、いま実現してる程度の量子コンピュータで解決できる問題って大して多くないらしい
2020/01/09(木) 23:23:42.79ID:lEkqwAZz
０か１かもつれあい。
白か黒かグレー。
はっきりせぇや！
2020/01/10(金) 08:16:14.21ID:JtrxktIj
D-waveは日立のスパコンに負けたし。
Googleも市販はまだだしな。

5年くらいはスパコンで構わないだろうな。
京の次のもスパコンだし。
2020/01/10(金) 09:08:00.29ID:XtFJsfLL
オワコン
2020/01/10(金) 17:33:40.71ID:D+gtbuRW
量子コンピュータは全ての状態保持してる時点でその中から特定の状態を求めたら今の計算機とやる事は同じなんじゃないのと思ってしまう
2020/01/10(金) 17:51:59.18ID:7no9JqrD
日本の裁判所が「Microsoft Teams」採用、民事訴訟手続きのIT化にて活用へ
https://cloud.watch.impress.co.jp/docs/news/1228574.html

＞日本マイクロソフト株式会社は9日、最高裁判所（以下、最高裁)が推進する民事訴訟手続きのIT化において、
＞コラボレーションツール「Microsoft Teams」が採用されたと発表した。
2020/01/10(金) 20:58:10.22ID:MGjCJLZH
>>750
お、うちも会社で使ってる。
2020/01/10(金) 21:26:45.39ID:JK7b4qpO
なんだって開発に32bitの古いマシン(8.1)にリモートで繋げてしなきゃいけないんだよ…
固まるわでストレス溜まる…

さらに HDD逝った可能性あって今日一日の作業がパー…
2020/01/10(金) 21:38:49.01ID:nS9kzoqj
銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？
2020/01/10(金) 23:40:11.60ID:x/cm2KaQ
VBAでいいじゃん
というかPythonで
と毎日思ってる
2020/01/11(土) 08:58:40.45ID:XtFXIsG9
>>753
オンラインサービスの構造がほとんど静的ならHTTPを調べる
動的ならSeleniumを調べる
2020/01/11(土) 10:05:16.19ID:AmOO0hUd
>>754
PythonでもいいけどC#なら尚良
2020/01/11(土) 13:43:37.82ID:vlDYQNOj
ダウンロードして後、どう利用するかで変わる。
それとその処理以外。

ダウンロードしたものをExcel上で何かの処理を継続して行うならVBAだけど、そもそも他の処理がExcel関係ないならそっちに合わせるべきでしょ。
758デフォルトの名無しさん
垢版 |
2020/01/11(土) 13:59:33.69ID:4eq7tLWK
おいらの腐った豆腐納豆の脳細胞だと
「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」
という判定をどうすればいいか、思いつかない
2020/01/11(土) 17:19:00.35ID:foXNNtpK
ダウンロードしたファイルのハッシュをチェック
2020/01/11(土) 17:39:59.19ID:9E0Dit0F
相手がハッシュ値を公開してないとだめよね
あるいはチェックサムを内部に持ってるファイルを受け取るか
2020/01/11(土) 20:09:19.45ID:PvCY8jLu
ダウンロードってそんな失敗するものか？
0.001%の失敗が致命傷になるのか？
2020/01/11(土) 22:55:43.90ID:vlDYQNOj
データのフォーマットがきっちりしてるならそれ自体がチェックになるから、それ次第。
2020/01/12(日) 05:36:04.93ID:Hfpc94Xd
失敗するときはするし致命傷にもなる
データがネットを経由する場合単なるIOとして処理してはならない
失敗したかどうかも判らないなんて論外
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
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況