大型 IT 公司如何防止運維偷窺和篡改資料庫?

像 BAT 這類公司,以及各種銀行,金融行業的 IT 運維,他們有著伺服器的最高許可權,那麼這種行業如何對運維的操作許可權進行審計和監管?

比如說騰訊的 Q 幣,支付寶的餘額,還有各種直播平台的手持身份證信息等等都是存在資料庫和伺服器磁碟裡面,如何防止運維直接查看和篡改這些敏感信息?


曾經在AppAnnie做過一段時間運維,分享一下AppAnnie的做法。

先說一些一些背景信息:AppAnnie有兩個相關的團隊,一個是運維,一個是安全。從線上操作來說,運維和安全的許可權是一樣的。研發團隊大多數人都沒有訪問生產環境主機的許可權,只有極個別Leader有權訪問,但是每次訪問都需要安全組授權,一般只有在處理緊急問題時才會允許。

接下來講一些具體的措施或者操作方法。

1、每個人(運維安全)都使用個人賬號登陸伺服器,不允許使用root登陸。線上的所有命令都會被記錄到系統日誌中,包括通過sudo執行的命令,SUDO_USER也會被記錄下來,因此主機上執行的所有命令,都可以找到是誰在什麼時間做的。所有主機上安裝了ossec,監控命令日誌,對於所有可能的敏感操作(如sudo、rm、對某些路徑的訪問等等),都會立刻發郵件到安全組+運維組的列表裡。因此,運維和安全組裡的任何人執行的命令,都是時刻接受兩個組所有人的監督的。除非你能找到漏洞繞過這個命令日誌監控,否則很難偷偷的做一些事情。

2、資料庫的主機有著更嚴格的安全策略。上面的防火牆設置了按會話流量切斷連接的的規則,一個SSH會話的流量超過100K之後就會強制斷開,因此,就算你想select *,然後手動從終端上複製數據出來,能得到的數據量都非常有限(更何況你執行的所有命令都有集體監督)。

3、研發人員有時候確實需要訪問一些生產環境數據的,需要向安全組申請。安全組同意後,由運維組寫腳本dump數據,這個腳本中會在dump數據時,將敏感信息隱藏掉(比如替換成無意義的隨機字元),這個腳本給安全組審查同意後,再去生產環境執行。最後把dump出來的數據拷貝回來。(拷貝時,會在防火牆上開一個臨時規則。)

總結的說,有這幾點:

1、制度上最小許可權原則。雖然你有root(sudo)許可權,但你不允許執行未經許可的命令,而且除非必要,不允許查看敏感數據。比如前面講的導出資料庫中的數據時,運維其實也是看不到生產環境中的敏感數據的。

2、相互監督。我們當時運維+安全+CTO共6個人,6個人都會接收命令日誌告警(但CTO沒有生產環境的賬號,他接收告警純粹是監督)。如果要做壞事,除非這6個人都達成一致,一起干。如果真的到這個局面了,那基本上就是CEO被架空了,這幫人要攜數據跑路了。

AppAnnie這樣做的代價是,凡是與安全相關的流程都很冗長,一件事要拖很久。除了上述提到的事情,平時研發團隊的代碼里如果要用到加密,那麼加密的演算法、參數也都是要安全組審查的,沒通過審查是不能上線的。代碼里所有的資料庫操作也都會有審查。而當時的安全組其實就一個人(其他都是實習生,沒有決定權,這個人曾經在某銀行做安全),這個人經常在世界各地的多個辦公室之間跑,因此常常一個審查要等上一周。但是公司層面願意為了安全而妥協上線效率。

我覺得,企業文化中的安全意識非常重要。國內的絕大多數公司,並沒有這樣的安全意識,大家的安全僅僅是建立在對人的信任之上,這是很可怕的。而且,在安全和更高的運作效率上,國內大多數企業是傾向於後者的,大家嘴上都說安全很重要,但實際上在大家的內心中,安全與我有何干?又不算KPI的。


1.職權分離,生產許可權只有生產支撐團隊有許可權,但是每次進入需要高級別審核,並且,只有指定機器,指定帳號才能用。通常,能接觸到核心的收入都非常高。。。。並且一次能接觸到的數據都非常有限。並且,都有記錄。

2.許可權最小化原則,訪問時,只給予當次所需要的許可權,比如申請後,給予有期限的隨機密碼等。

3.核心機器直接無法連接外網,有的還得要各種key才行。

4.風險控制團隊周期審核系統許可權,審計操作,審計系統安全

5.還是會丟。。。。。比如騰訊丟過qq群整個庫,比如銀行丟過客戶資料,想想保險電話。。還有些黑客發現了銀行漏洞,要挾給比特幣呢


看了一圈基本都是從制度、流程和規範角度的,我來說一個技術角度的好了:

首先,使用內容分布的資料庫,舉個例子來說,除了UID作為用戶統一的標識符以外,一些關鍵性的數據,例如Hashed Password,以特定的方式被分為2個部分各自放置在一個獨立的庫中,兩個庫完全進行獨立的管理。當用戶提交諸如密碼登錄申請的時候,登錄伺服器會在收到本地上傳的加密密碼後,將其中兩個部分分別進行比對。

而負責拆分比對這部分的核心代碼,則是使用我們自己稱為Guardian的機制,即:

Guardian所對應的介面代碼,放置於SVN上的部分,分為2個文件,並且提供了各自的拆分介面。然而這個介面及內部的代碼是偽造的,當伺服器端需要正式更新版本時,兩個部分的業務負責人(這是最核心的保密人員),會各自用手上那份真實版的代碼,替換掉SVN中對應的兩個文件,並重新編譯發布。發布則由第三方的負責人進行

由於每個人手裡都拿不到完整的真實代碼,因此基本不存在偷窺到完整資料庫的情況。由於用戶數據是被加密後拆分放在兩個獨立的庫中,平時的維護人員及時擁有某一個庫的許可權,也無法從中讀出有意義的數據。同樣的,即使兩個庫同時失竊,由於包括ID在內的部分都是重新加密過的,沒有伺服器端的加密器也無法解碼出對應的數據。

舉個例子來說

UID:= 1234,Hashed_PW:=abcdef

在A庫中,取UID前70%和Hashed_PW的所有奇數位以及前三位,計算後構成新的ID和PW欄位

在B庫中,取UID的後70%和Hased_PW的所有偶數位以及後三位,計算後構成新的ID和PW欄位


作為運維狗,終於有了能在知乎上答的問題了。

主要從事前審批,事中監督,事後審計三個方面來進行管理和控制。

1.事前審批。用職權分離、最小授權和檢查審批。能接觸數據的人必需要拿到審批,沒審批去接觸、修改數據的,只要發現一次你就完蛋了。以盡量少的人,和盡量低的許可權去接觸數據。登錄前會過幾道關,來檢查你是否有審批。

2.事中監督。以網路物理隔離、門禁、登錄用key,來保證你必須在指定地點才能登錄。操作全程受到專人檢查和監督,保證操作的內容與審批內容相符,登錄用戶有多個級別,一般使用最小許可權用戶,能使用root的一般只能是dba。

3.事後審計。審計系統、堡壘機。登錄時必須先登錄堡壘機,再由堡壘機登錄資料庫,操作過程全程視頻錄像,以上用來保證事後可被審計。事後由專門崗位進行日常審計,檢查操作與審批內容相符、使用最小授權用戶登錄等等各種合規檢查。

審計稽查部門會進行全流程檢查,以保證各個環節都是落實到位的。

總之,你想干點什麼,分分鐘就給你查出來,你要豁的出去,想干就干吧!


銀行卡里餘額隨便改不了,必須有對應多個系統的業務流程聯動才能修改,即使你改了,也會在其他系統里體現出來。比方說你在銀行核心系統的資料庫里改了餘額,但是對應的會計平台沒有相應的業務流程記錄,這時沒有對應的業務流程給對應卡號充值(轉賬),兩邊定時批量對賬,一有不符就需要審核啦。

總之一句話,銀行里,技術上(業務流程上):隨便一個賬號里數字(錢)的改變,都對應了多個複雜系統的聯動。即使你了解了所有業務,熟悉所有系統操作和擁有許可權,核心資料庫的操作都有記錄。而且,也有審計、風險部門的審核。


這是準備給區塊鏈做廣告嗎


銀行數據可能還有點兒用,BAT的數據你拿了能賣多少錢,被抓到了至少也是開除,而且名聲壞了,以後也不好找工作了,值得么。。。

就算能賣點兒錢,你要知道針對屁民,犯罪門檻其實特別低。破壞計算機系統罪,隨便干點兒啥就夠判刑了。偷了賣錢這個不知道會算成什麼罪,但我估計十幾萬就足夠你在監獄裡度過一半的人生了。。。


身為運維前來答一下。

第一,運維首先是有自覺的。來上班,是為了安穩掙錢,如果偷數據改數據什麼的。還不如去做黑產來得快。

做過運維之後,基本上常見的漏洞了解於心了。不多說。

第二,生產環境的數據許可權是在DBA那邊。一般不會改,有風險。而且也改不到。

第三,如果擔心,作好許可權管理與許可權 限制就可以了。一個領30W年薪的人是不會做出這種毀自己前途的事情。但是一個小工幾千塊的,就有可能被利蒙掉了心。

總之是賞罰並重吧。具體的許可權管理每家公司都不一樣。不再詳述了。


咳咳..


1、為什麼運維會有資料庫的密碼?這不是DBA的事兒么?

2、運維也不是每個人都有root許可權啊。

3、我還是不懂一個沒有root許可權的人怎麼偷偷做事情……我一連資料庫就被警告了。


根本預防不了。只有法律的懲戒,才能讓部分人放棄想法,鐵了心要做的,任何制度,流程,手段都不起作用。


實在是看不下去@WarMonkey 這個人的胡說八道了,什麼叫法律規定互聯網公司只能保存用戶的明文數據,要是你制訂法律,你會制訂這麼腦殘的?什麼又叫做只保留加密數據就萬事大吉?你以為解密的都是如你這班不學無術只會來逼呼坑蒙拐騙的?不懂,就好好看看下面那些做運維的專業人士的回答。其他人不要被這種自以為民科的人給騙了,長點心吧。


1. 職務不相容分離原則。將工作按內容區分為不同的崗位,根據崗位來劃分許可權,相互制約。

2. 許可權最小化原則。僅給予滿足工作所需的最小許可權。

3. 完整有效的第三方日誌。配置完整有效的日誌,且獨立於運維人員來管理,用於事後查證。

4. 操作的封裝。建立一些特別的中間件,將常用的操作封裝起來,運維人員僅能調用預設的指令來進行維護操作,而難以直接接觸最底層的系統來執行任意命令。

5. 所有一切的核心還在於人。通過以上各種方法,是能夠將監守自盜的風險降到很低的,大家都是聰明人,當可能的收益與風險做出對比後,大多數人都不會去做那種得不償失的事。當然員工的價值觀層面教育也還是需要跟上的,真正有一定規模的公司,這方面其實都不太成為難題。許可權越高的人,其限制其實也越多的。許可權越低的人,其能夠做的事也很少,難以產生根本性的危害。


反對 @WarMonkey

你該問問你的隱私數據在哪個環節泄露了

雖然隱私泄露是常態,但遠遠還沒到國家那層。遠在之前就被泄露了,國家要求實名制、登記手機號,只是更方便各個公司來做這件事情,風險集中在公司,而不是國家。

實名制完全可以對標徵信系統。。。前者是把用戶信息放在公司那裡,後者是一個國家金融為中心的徵信體系。。。倒是很期待實名制中心化

另外,我國的電信行業確實是可以監聽用戶隱私的,誰讓通訊的數據全部從運營商流過而且我們又沒有法案來保護這件事情呢。然後用來做廣告劫持了,這才有了HTTPS。斯諾登這才過去多長時間?

我們都知道,最徹底的保護數據的方法,是對用戶數據使用用戶密碼進行加密。只在公司伺服器保存加密的數據,不存留原始數據。如此之下,偷看資料庫變得沒有意義了。

道理雖然是這樣,並且確實可以實現。想保持在透明的環境中還得保持加解密。可以啊,HTTPS這種在RSA換個密鑰,然後在AES上傳輸就行。資料庫正文。。不排除大型公司可以一個用戶一個加解密的公私鑰,全部客戶端加密解密,什麼評論內容放在 服務端只存密文。但這樣的技術成本巨高無比。

這樣做了之後,大公司里怎麼做數據運營?情感分析還要不要?輿論分析怎麼做?怎麼用來評判效果。你評論了之後,還能不能讓別人看到這個評論,如果能,那你的評論內容應不應該用明文?如果不用明文,那不就是其他用戶都得知道你的解密密鑰?效果上和用明文有區別嗎?解密密鑰是你在線的時候由你P2P傳輸過去,還是給服務端?P2P你下線了其他人就看不了你的文章了?服務端那和明文有區別嗎?

更何況一個用戶要自行維持自己的公私鑰,這種事情給程序猿弄個ssh key就很不錯了,讓每一個用戶做。。。。你知道只要數據量上來了,總會有20%或者更多的用戶在用最常見的10個密碼(123456等)嗎?

然而,加密用戶數據,與中國的法律法規相抵觸。國家不允許用戶加密自己的數據並且讓網路公司無法解密。

借用某位朋友的評論:

1.法律規定網路公司有配合各種調查的義務。

2. 法律規定網路公司必須能查看明文數據。

這也叫是說,他偷看用戶隱私是一種受法律保護的權利。 換句話說,通過技術手段不讓人看隱私這個事情本身就違法。

法律規定網路公司有配合各種調查的義務。這條沒錯,這不就和你走路上作為目擊者,應該配合警察調查一樣的么?而且我國的審查環境大家都知道,尤其是UGC內容,必須先審查,不然封你沒商量。

必須能查看明文數據

這條沒聽過。這真是為黑而黑,請你給出對應的法律條文,起碼在我司這種上億活躍用戶的公司,聞所未聞這樣的法律。《網路安全法》說的是:

第三章 網路運行安全

第一節 一般規定

第二十一條 國家實行網路安全等級保護制度。網路運營者應當按照網路安全等級保護制度的要求,履行下列安全保護義務,保障網路免受干擾、破壞或者未經授權的訪問,防止網路數據泄露或者被竊取、篡改:

(一)制定內部安全管理制度和操作規程,確定網路安全負責人,落實網路安全保護責任;

(二)採取防範計算機病毒和網路攻擊、網路侵入等危害網路安全行為的技術措施;

(三)採取監測、記錄網路運行狀態、網路安全事件的技術措施,並按照規定留存相關的網路日誌不少於六個月;

(四)採取數據分類、重要數據備份和加密等措施;

(五)法律、行政法規規定的其他義務

第四章 網路信息安全

第四十條 網路運營者應當對其收集的用戶信息嚴格保密,並建立健全用戶信息保護制度。

第四十一條 網路運營者收集、使用個人信息,應當遵循合法、正當、必要的原則,公開收集、使用規則,明示收集、使用信息的目的、方式和範圍,並經被收集者同意。

網路運營者不得收集與其提供的服務無關的個人信息,不得違反法律、行政法規的規定和雙方的約定收集、使用個人信息,並應當依照法律、行政法規的規定和與用戶的約定,處理其保存的個人信息。

第四十二條 網路運營者不得泄露、篡改、毀損其收集的個人信息;未經被收集者同意,不得向他人提供個人信息。但是,經過處理無法識別特定個人且不能復原的除外。


補充一點,很多大型企業的資料庫,庫表結構異常複雜。如果沒有數據字典,沒有欄位說明文檔,甚至沒有專門的培訓,普通開發人員都沒法搞清楚裡面的數據代表著什麼業務數據。

不少運維人員不懂開發,有的不懂資料庫,偷窺了也看不懂,篡改更加是無從下手。

從信息安全出事的歷史事件角度,一般內鬼都是負責相關應用子功能模塊的開發人員或者DBA。


有操作記錄可審計的呀!除非你不想活了,可以趁著有許可權來一次瘋狂破壞。然後淡定地對你領導說:你報警吧。接下來,你就會開始平淡而刺激的牢獄生涯了。。。

但是,然並卵。。。理論上分分鐘就恢復啊


對於生產環境的伺服器,你只能去固定的系統登錄,該系統對你做的任何操作都會記錄;

只有某運營團隊數據外發許可權,運維只給該團隊領導及相關提供日常數據,非日常數據需要領導審核


本人並不是大型IT企業,但也是大型企業,運維許可權很高,但也分的很細,監管制度很完善,出了事,很容易就能定位到人,除非是惡意破壞,商業間諜之類的,否則那些數據的價值,遠不值被發現後的懲罰,犯罪成本太高


干過銀行運維,上面靠譜的答安基本銀行有過之而無不及。

不過說實話,我覺得最有效的其實是物理隔離,銀行伺服器機房用的都是專線,專線連一個交易室,有改資料庫記錄許可權的機器在這裡面。

要改數據要找人通過層層審批刷開防盜門頂著監控進去敲命令...


如果數據不是那麼敏感,只是涉及到餘額之類的信息,就沒必要瞞著運維。

如果想當敏感,比如雲備份的聯繫人信息,數據需要加密存儲,密鑰也存儲在雲端,有獨立的運維團隊維護密鑰存儲。密鑰的運維和數據的運維相互獨立,確保沒人可以同時接觸到密文和密鑰。

如果數據極其敏感,數據寧可丟失也不能落入他手的,比如雲備份的裸照,不僅需要加密存儲,而且密鑰只能存在用戶自己手裡,雲端不能存。忘了密碼,數據就相當於銷毀了。


推薦閱讀:

一個網站的用戶資料庫被入侵的方式有哪些?運維和管理人員如何防範?
互聯網公司需要什麼樣的運維工程師?
互聯網運維工作有趣嗎?
系統工程師和系統運維是兩個不同的職位嗎?
都說docker是運維大神,想了解一下docker在web server運營上都有哪些用武之地?

TAG:程序員 | 編程 | 網路安全 | 黑客Hacker | 運維 |