推 AmadeGX:笑翻XDDD 快學起來(不對 12/20 16:23
→ gname:這叫作置之死地而後生~ 12/20 16:24
推 vvppqqvv:在我待過的公司這樣就被LAY了八 12/20 16:43
→ vvppqqvv:我是覺得下之前也應該放在測試資料庫跑一次看看 12/20 16:44
→ vvppqqvv:會這樣大概都是習慣不好 12/20 16:45
→ hichcock:帥!! 這是變相的轉個彎系列吧 12/20 16:46
→ vvppqqvv:而且這位前輩的環境就算沒有內稽內控規範也不能鐵齒 12/20 16:46
→ TonyQ:還是認真做備份吧，我現在都會乖乖做備份了=_= 12/20 16:47
→ TonyQ:其實兩個部份都有問題，沒有備份的問題比較大，另一方面是 12/20 16:47
→ TonyQ:寫 update 之前還是盡量先寫完 where 再寫修改內容 12/20 16:48
→ qrtt1:嗯。先寫成 select 看一下範圍是很重要的習慣啊 12/20 16:48
推 AV5566:其實還滿聰明的..XD 12/20 16:58
→ vita224:先select +1... 12/20 17:02
→ kvjo:我覺得要加薪 想到這個方法的人 這個人有頭腦 12/20 17:04
→ kvjo:減薪造成這個失誤的人 不夠謹慎 12/20 17:04
→ kvjo:如果都是同一人 ....哈哈哈 XD 12/20 17:04
推 bohei:想到的人很威... 12/20 17:12
→ a926:同意q大。現在有動到刪除、更新..都會用SELECT確認一下 12/20 17:14
→ alan3100:如果是工具的話別用autocommit 12/20 17:24
推 mathrew:我幹過兩次類似的事情，不過不是改密碼 是改線上系統 12/20 17:37
推 astt88:個人一定會先Select後將結果備份，然後再寫Update 12/20 17:55
→ astt88:如果是正式環境，還會先做一次完資料庫備份 12/20 17:56
→ tooto1985:萬一手滑了,你不就出包了? 12/20 17:57
→ tooto1985:第一次不小心打錯...第二次打正確的...永遠都進不去了 12/20 17:58
推 alan3100:樓上那個好解 連續2次一樣才當正式密碼 12/20 18:00
推 gmoz:UPDATE的話都會用編輯工具 囧 驚驚 12/20 18:01
推 chrischen:update delete 單筆的話 必定搭limit 1 12/20 18:11
推 crossdunk:難怪有時候輸入正確他也跟我說不正確,原來..XDD 12/20 18:19
推 legendmtg:這哪招啊XDDDD 12/20 18:22
推 dylan29341:拿 production 做測試本身就是個錯誤 Orz 12/20 18:30
推 ken1325:原來還有這招，誰想到的阿XDDDD 12/20 18:36
→ realmeat:資料不進行備份的公司還漫酷的.. 12/20 18:39
推 ggg12345:普通用戶在終端機設陷,找機房管理員偷root帳號的變形老招 12/20 18:41
→ realmeat:線上資料 測試資料 線上程式 測試程式也沒切開 12/20 18:41
→ realmeat:我怎覺得管理面的問題比失守犯錯的問題大多了 12/20 18:42
→ StubbornLin:這樣幹的話 要登入任何一個人的帳號只要在他之前 12/20 18:44
→ StubbornLin:輸入兩次同樣的密碼就... 12/20 18:44
→ ggg12345:魚怎麼會知這是有鉤的魚餌?搶食到食物的魚都會帶食快離去 12/20 18:50
推 vvind:同樓上，我也想到這問題 12/20 18:53
→ vvind:StubbornLin 12/20 18:53
→ freeunixer:那要有人知道密碼被刪掉,正在等使用者自己來 update. 12/20 19:15
推 f1234518456:沒有寫備份script喔... 12/20 19:28
→ pooznn:習慣先寫select 看對不對 再下去改 12/20 19:57
推 LaPass:看了我只想說聲幹(讚美意味) XDDDDD 12/20 20:15
推 givemepass:XDDDDDDD 蠻有趣的 12/20 20:48
→ leiyan:硬要說使用者忘記了要你改怎麼樣 12/20 20:56
推 et282523:真是高招啊，學起來！ 12/20 21:15
推 dnzteeqrq:呵呵 動正式資料一定都會先下 transaction 12/20 22:21
→ andymai:再怎麼簡單的sql也要在測試環境先下吧?沒測過就在正式機下 12/20 23:16
→ andymai:真的很有勇氣... 12/20 23:17
→ andymai:如果使用者忘記了也簡單~就說編碼過無法直接看到原碼~給他 12/20 23:18
→ andymai:一個新的密碼~再請他上去改成他要的就好了 XD 12/20 23:19
→ andymai:剛剛想到另一招~就是使用者不管打什麼都過~但是基於定時換 12/20 23:27
→ andymai:密碼的理由~請他再打一次新的 XD 12/20 23:27
推 chikasa:這真的....XDDD 12/20 23:31
推 whackup:很多人說不備份 但這種鳥公司真的還不少... 12/20 23:49
推 kunchung:題外話!開發人員不應該在正式環境下SQL吧! 12/20 23:50
→ lion0208:沒人覺得密碼是明碼本身就有問題嗎... 12/21 00:21
推 kunchung:樓上!人家的語法又不是update明碼! 12/21 00:23
→ lion0208:oh, 沒注意到有個 pass function :p 12/21 00:25
推 ggg12345:釣魚時,硬說定期該換密碼但輸入驗時不符(*看不見)不生效! 12/21 01:04
→ TonyQ:其實這個案例背後本身真的有很多值得再討論的事情，XD 12/21 04:27
→ TonyQ:從環境來看好了，定期備份（至少一天一次）是很重要的。 12/21 04:27
→ TonyQ:有些比較嚴謹的地方是一天一次完整備份，每小時作差異化備份 12/21 04:28
→ TonyQ:然後再從 SQL 面來看好了，其實工程師真的不該在 production 12/21 04:28
→ TonyQ:上硬要用 sql 改，最好都是透過在 dev 上用寫系統的方式改。 12/21 04:28
→ TonyQ:這樣可以避免白痴 user 作白痴事，至少第一次作對，後面別人 12/21 04:29
→ TonyQ:都不用擔心，而第一次的問題就發生在 dev。 12/21 04:29
→ TonyQ:然而總是會有 bug ，所以確實把一些邊界條件（ex. limit 1) 12/21 04:29
→ TonyQ:之類的檢查做好也很重要。 12/21 04:29
→ TonyQ:然後我本來以為只是個案，昨天看 FB 迴響發現真的不少地方 12/21 04:30
→ TonyQ:都有做過類似的事情。拜託請大家正視 SQL 備份的重要性。XD 12/21 04:30
→ TonyQ:根據經驗，很多地方不是沒資源作備份，是沒人注意到要做這件 12/21 04:31
→ TonyQ:事...Orz 12/21 04:31
推 ggg12345:整串已從備份容錯.變成失誤後,是否可廢墟中簡易快速復原. 12/21 07:15
→ ggg12345:帳密因有散布的使用者記憶,可從這些分散於用戶的記憶備援 12/21 07:17
→ ggg12345:容錯復原甚至廢墟中可復原仍不脫有分散的多餘性備份備援. 12/21 07:21
推 ggg12345:從分散的備份資料詐出重要情資,那又是資料保護與洩密問題 12/21 07:27
→ ggg12345:密語明碼雖經轉換,但屏蔽釣魚還是能從分散記憶中取走密語 12/21 07:53
→ ggg12345:接下去就是防護系統能否偵測出分散備份情資是否被詐洩密? 12/21 07:58
推 eacdpizzy:其實這樣不是也有風險，假如我正在破解這帳號的密碼.... 12/21 08:37
→ viceversa56:前陣子YAHOO很多帳號被強迫換密碼 該不會和這有關? 12/21 09:57
→ viceversa56:這招也不是很好 像我密碼有好幾組 錯了我會換另一組 12/21 09:59
→ viceversa56:常用密碼測試 12/21 10:00
→ viceversa56:還有就是帳號打到別人的,密碼打到自己的這種情形 12/21 10:02
→ astt88:其實為了一個SQL的錯誤，要改使用該資料的應用程式 12/21 11:07
→ astt88:只能說，這不是一種好方法 12/21 11:07
→ astt88:另外，我個人在寫非SELECT的SQL指令時，會包在註解裡 12/21 11:08
→ astt88:以免不小心按了全部執行 12/21 11:08
→ astt88:個人一向認為，所有的資料庫變更應該要由應用程式來做 12/21 11:09
→ astt88:應該要避免直接在資料庫中執行SQL指令 12/21 11:11
→ astt88:尤其是Update、Delete、Insert。我認為這是走後門的做法 12/21 11:12
→ astt88:但我接觸的客戶跟老闆，都認為直接下比較方便 12/21 11:13
→ astt88:上面寫的解決方法有資安問題，只是個掩飾錯誤的做法 12/21 11:15
→ astt88:過段時間一定要改回來，再加寫忘記密碼或密碼重置功能 12/21 11:17
推 giantwinter:這沒被FIRE算奇蹟 12/21 11:18
→ astt88:其實看過很多系統，不是沒有備到份，就是備份無法回復 12/21 11:18
→ astt88:所以不是有備份到就行了，還必須要能復原 12/21 11:19
→ astt88:讓我想起很久以前，被客戶要求星期日來做異地備援備份與回 12/21 11:20
→ astt88:複演練。在演練前還要把動作及時間寫成文件，然後照做 12/21 11:21
→ astt88:若有失誤或時間內沒有做完，就會被要求檢討改善 12/21 11:22
→ astt88:因為會被FIRE，所以才會想到要用這樣的方法來解決 12/21 11:23
→ astt88:工作 vs 資安，當然是工作比較重要 12/21 11:24
推 derekhsu:抄起來了 12/21 11:53
推 GoalBased:發封信說為增加密碼安全請使用者定期改密碼，之後當下 12/21 14:36
→ GoalBased:強迫他去改密碼 這樣如何? 12/21 14:36
→ astt88:要改密碼，在正常的程序是必須成功驗證過密碼的 12/21 23:44
→ astt88:沒有密碼，還想要改使用者密碼，就必須要另外檢核使用者的 12/21 23:45
→ astt88:身分，也就是忘記密碼功能。如果只有一、二個人的密碼被改 12/21 23:46
→ astt88:還可以硬說是使用者忘記密碼了，但如果是整個資料表就很難 12/21 23:47
→ astt88:說得過去，必須要掩飾錯誤 12/21 23:48
推 zo4j4:看推文長知識 12/22 00:54
推 LINGZ:astt8,我觀念跟你一樣,DB資料的變更應由AP而非DBA.從業以來 12/23 14:02
→ LINGZ:遇到一個很特別的客戶,AP有提供系統功能修改資料,但客戶要求 12/23 14:02
→ LINGZ:把系統功能從授權移除,資料維護廠商一律提供SQL腳本... 12/23 14:03
→ LINGZ:執行資料維護的系統功能都有log,並需放行後資料才會生效. 12/23 14:05
→ LINGZ:結果居然都要求提供SQL,真是特別! 12/23 14:06
推 LINGZ:另外問一下astt88,您被客戶要求週日做備援演練,有收費嗎? XD 12/23 14:09
→ astt88:因為是做異地備援案，所以應該沒有額外收費 12/23 22:12
→ astt88:異地備援案的金額我不知道，那時我不是正式的員工 12/23 22:13
→ astt88:所以假日去客戶那邊做備援演練，只能換補休 12/23 22:14