符合PCI的Web應用開發指南:PCI是線上支付必過關卡
上次更新工作進度:01-26-2012 Ken Cochrane著
我三年半前剛開始在CashStar.com公司工作時,曾經聽說過PCI,但並不真的知道它的含義。那時我們正在構建一個可以通過網路來接受信用卡交易的商務平臺,我發現必須保證我們的平臺完全符合PCI規範。由於我們是“第一個吃螃蟹”的人,沒有太多的錢,而且所犯的任何一個錯誤都可能毀了公司,所以我也不想成為其中一個犯錯誤的人。我花了大量的時間來研究PCI,以及它到底做了什麼保證web應用程式足夠安全。
我做的第一件事情是先在網路上簡單的搜尋了一下資訊。我驚訝的發現網上真的沒有太多可用的資訊。而且很多可用的資訊也並不使人易於理解,甚至還有點模糊。當然可以請一些公司來指導你走遍整個交易過程。但是既然我們沒有太多的錢,所以這對於我們來說也不是一個可選的選擇。所以我做了任何極客在這種情況下都會做的事情。當我實現了完全符合PCI規範時,已經竭盡所能的花了大量時間閱讀PCI相關資料,並對其進行了研究,終於用自己的方式從PCI這座“地獄”裡“越獄”出來。
我貼這篇部落格的目的是把自己所有的經驗教訓寫下來,這樣就能幫到其他人瞭解整個過程。同時在將來需要再次使用PCI的時候,它能作為一種提醒,讓我回憶起上一次的每個細節。我希望把它弄成一份“鮮活”的的文件。隨著時間流逝和情況變化,我將盡力實時更新。如果你注意到某些內容不正確或者有什麼遺漏,請發表評論。我將盡全力一有機會就更新。
快速連結
• 什麼是PCI?
• PCI通俗解釋
• 如何開始?
• 自我評估調查問卷
• 外部審計
• PCI 2.0
• 細節
• PCI常見錯誤
• 令牌標記
• 資料中心
• 安全掃描
• 入侵檢測系統
• 彩虹表和加鹽值
• 相關連結
什麼是PCI?
大多數人問的第一件事情就是“什麼是PCI?”。PCI是“支付卡行業安全標準委員會”(Payment Card Industry Security Standards Council)中的Payment Card Industry簡稱。它包括American Express、Discover Financial Services、JCB、MasterCard和Visa,於2006年9月7日成立。
建立PCI SSC的主要目的是提供一套通用的可供商戶使用的安全標準,使他們能更好的保護自己免於黑客攻擊。PCI SSC也提供了支付卡行業資料安全標準(Payment Card Industry Data Security Standard,PCI DSS)。它包含了12種要求和多種子要求。這些商戶需要遵照的要求可使他們接受PCI SSC成員的借記卡、信用卡、預付卡、ATM或POS卡交易。
為什麼要建立PCI?
- 建立它是為了對付資料安全漏洞。
- 指導商戶。當涉及持卡人資料交易時,能幫助他們確信他們正在遵照最佳安全實踐。
PCI對我有影響嗎?
- 你是否接受信用卡/借記卡的線上支付或電話交易?
- 信用卡資訊是否傳送到你的伺服器上?
- 你是否儲存信用卡資訊?對它加密嗎?
如果這些問題你都回答yes,那麼PCI至少以一種或其他更多種方式在影響著你。
PCI DSS 要求
這裡羅列了PCI DSS 的12種要求。你看完之後,會發現其中有很多種要求並不是那麼複雜,並且可能已經在這麼做了。其中很多種也僅僅是常識,但依然能讓很多不知道的人感到驚奇,即使它們只是常識。
- 安裝和維護防火牆設定,保護持卡人資料。
- 不要使用承包商提供的系統預設密碼和其他安全引數。
- 保護已儲存的持卡人資料。
- 加密傳輸持卡人資料到公共開放網路。
- 使用和常期更新所有普遍受到惡意軟體影響的系統上的反病毒軟體。
- 開發維護安全系統和應用程式。
- 禁止訪問只有業務人員需要知道的持卡人資料。
- 為每個訪問計算機的人分配一個獨立的ID。
- 禁止物理訪問持卡人資料。
- 追蹤監控所有對網路資源和持卡人資料進行的訪問。
- 常期測試安全系統和交易過程。
- 維持一個用來解決資訊保安問題的公司政策。
PCI通俗解釋
- 所有商戶,無論是否儲存了信用卡資料,任何時候都必須做到和保證自身行為符合規範。
- 商戶不能儲存特定信用卡資訊,包括CVV、追蹤資料、磁條或PIN資料。
- 如果要儲存已經過允許可儲存的信用卡資料,需要遵照PCI安全標準用一種安全的方式儲存。
如何進行PCI認證工作?
可以像下列這樣執行PCI認證工作。如果想接受信用卡或借記卡交易,需要同意自己會在任何時候維護PCI認證。有很多方式可以確認是否已被認證。填寫一份自我評估調查問卷(Self-Assessment Questionnaire,SAQ),再填寫一份合規報告(Report on Compliance,ROC。是所有經受支付卡行業資料安全標準審計的一級Visa商戶必須完成的一種表格。——譯者注)。我會在之後說明兩者之間的細微差異。但其中,需要記住的重要部分是填寫一些檔案,然後經常傳送給請求出具這些檔案的人或公司。他們經常是那些辦理信用卡和處理商戶帳號的公司。
- 填寫一份自我評估調查問卷(SAQ)並知曉自己屬於哪個商戶級別。
- 確保遵照該商戶級別建議。
- 修復任何問題。
- 立證宣誓符合規範(如果正在自我評估中)。
- 外部審計(如果有需要的話)。
如何開始?
- 確認企業組織中有專人負責PCI規範,並組建一支包含來自各個領域成員的團隊。
- 確定商戶級別(1級到4級)。
- 確定何種SAQ是企業組織需要完成的。
- 評估企業組織是否已盡全力在內部做到符合PCI規範或僱傭了一位認證安全評估專員(Qualified Security Assessor,QSA)。
- 僱傭一家獲批掃描承包商公司(Approved Scanning Vendor,ASV),開始進行外部IP漏洞掃描工作。
- 確保企業組織有一個資訊保安政策,並正在強制執行中。
- 在評估或掃描工作中,立刻解決任何已發現的明顯不足之處。
- 保留自我評估、掃描和後續工作記錄。準備一有要求就提供這些檔案。
我屬於PCI哪個級別?
這裡有4種PCI規範級別。一年中辦理多少筆交易決定你屬於哪個級別。
商戶級別
級別1: 每年辦理600多萬筆交易的商戶(所有渠道)或被任何Visa地區認證為1級全球商戶。
級別2: 每年辦理100萬到600萬筆交易的商戶(所有渠道)。
級別3: 每年辦理2000到100萬筆Visa電子商務交易的商戶。
級別4: 每年辦理2000筆不到的Visa電子商務交易的商戶和所有其他每年辦理高達100萬筆Visa交易的商戶。
要求
級別1:每年執行要求的現場安全評估工作。每季度執行要求的網路漏洞掃描工作。
級別2:商戶根據自身情況自行斟酌執行現場安全評估工作。每年填寫要求的自我評估調查問卷。每季度執行要求的網路漏洞掃描工作。
級別3:每年填寫要求的自我評估調查問卷。每季度執行要求的網路漏洞掃描工作。
級別4:每年填寫要求的自我評估調查問卷。每季度執行要求的網路漏洞掃描工作。
RoC或SAQ?
如果你是1級,那麼要填寫一份RoC。如果你是2、3或4級。那麼要填寫一份SAQ。這些規則也有例外之處。比如,如果在過去存在過一個安全漏洞,信用卡公司會要求你完成一份RoC,即使你不是1級。
合規報告(RoC)
如果每年辦理了600多萬張信用卡(1級),會被要求執行一次現場PCI評估工作,並由認證安全評估專員(Qualified Security Assessor,QSA)出具一份合規報告(Report on Compliance,RoC)。其他2級企業組織也會被要求傳送一份RoC或自己選擇傳送RoC以爭取成為1級商戶。
也可以用QSA提供這樣的年度稽核。它包括對在PCI規範範圍內的網路、伺服器和資料庫確立的過程和流程進行稽核。這些工作包括對企業組織中的相關干係人的面試稽核、對支援性檔案的稽核、對規範計劃的驗證和完成報告其本身。
QSA常鼓勵它們的PCI客戶在一整年中使用PCI規範管理解決方案。這會幫助他們保證自己的日常運營情況符合PCI規範;執行現場評估工作;更快更順暢的完成RoC。
自我評估調查問卷
這裡有5種SAQ分類。你屬於哪一類將決定檔案填寫工作是相當簡單還是需要花費更長的時間。5種分類如下:
SAQ-A:所有涉及持卡人資料功能的工作都被外包出去,不用出示卡(電子商務或郵件/電話訂單)的商戶。這不適用於面對面的交易。
SAQ-B:不能儲存或只能獨立儲存而不能線上儲存持卡人電子化資料,只能蓋印的商戶。不能儲存持卡人電子化資料,擁有撥號終端的商戶。
SAQ-C-VT:只能使用基於網路的虛擬終端,不能儲存持卡人電子化資料的商戶。
SAQ-C:有連線到網路的支付應用系統,不能儲存持卡人電子化資料的商戶。
SAQ-D:所有其他不包括上述SAQ分類A到C描述的商戶和所有被某支付品牌認為有資格完成SAQ的服務提供商。
既然這裡只討論web應用,所以你極有可能是A、C或D類商戶。一旦你知道自己屬於哪個分類,則要填寫該類的SAQ。一旦完成了此類的SAQ,也要立證宣誓自己行為將會符合規範。
這裡有一份很有幫助的指導指南,幫助你知道自己屬於哪個分類。
SAQ-A
A類中有很多不盡相同的部分,但其中最重要的一部分是不能讓信用卡資料和你的伺服器發生關係。做到這點最簡單的方法是當你要人們輸入信用卡資料時候,重定向這些資料到其他第三方公司的伺服器上。貝寶(Paypal)、谷歌網路支付(google checkout)和亞馬遜支付(Amazon payments)普遍都這麼做。
另外一種實現這點的方法是讓信用卡閘道器host支付網頁。這樣做的一個例子是authorize.net公司的Simple Checkout。
第三種實現這點的方法是所謂的“transparent redirect”或“Direct Post”方法。BrainTreePayments 公司是第一家用這種流行方法實現這點的公司,但之後Authorize.net公司也增加了這種方法,作為第二種方法的一個替代方案。
最後還有一種方法,基本上和第三種方法很類似。但它是用javascript來加密信用卡資料,並將資料傳送給信用卡資料處理器,然後用唯一的令牌填入表單以供之後使用。這種方法stripe公司正在用。 BrainTree和livingsocial公司將這種新方法稱之為端對端信用卡資料加密法(端對端即點對點的兩端電腦的直接連結——譯者注)。
SAQ-C
如果你正在host支付表單到伺服器,點選表單中的提交按鈕,傳送表單資料到伺服器,然後解析表單資料,將信用卡細節資料從表單欄位裡抽取出來,建立自己的web請求,並在之後將它傳送到自己的信用卡資料處理器中,那麼此時你至少是個C類商戶。即使你不打算儲存資料,因為信用卡資料也可用於計算機記憶體中並且你的程式碼正在和它打交道,所以這裡極有可能會發生某些風險並且能夠獲取對它的訪問權。
SAQ-D
如果你不屬於其他種類商戶,那肯定是D類商戶了。SAQ D有時候也被稱為“輕量級”ROC,因為任何屬於SAQ D類商戶的企業組織儘管其規模不大,但它們也基本上通過了所有12種PCI DSS要求。
PCI成本是多少?
這真的很難為此得到一個精確值,因為它對每家商戶來說都會不同。但是可依據這篇BrainTree公司的文章“how much it costs to become PCI Compliant”中的一張表格來估算:
外部審計
如果你的公司夠大或夠不幸到需要外部審計,這可不便宜啊。審計工作會持續好幾周或需要更多的在現場工作。請低端審計公司審計也要花費2萬到3萬美金,普通公司大約是一年22.5萬美金,如果是排名前10%的審計公司則要花費50多萬美金。正如你所見,每年這樣花費的成本真的很昂貴,所以應該儘可能的避免。
這裡也重要的指出一點:這些成本只是審計工作本身所花費的成本。如果審計公司在審計中發現任何錯誤,你需要在他們認為你審計合格之前支付花在修復任何審計問題上的成本。
這裡有一些連結,我是從它們那裡得到資料的。
- http://www.networkworld.com/news/2010/030110-pci-compliance-audit-cost.html
- http://blog.elementps.com/element_payment_solutions/2009/02/pci-compliance-costs.html
- https://www.infosecisland.com/blogview/12356-Five-Questions-to-Ask-Your-PCI-Auditor-Before-You-Hire-Them.html
PCI 2.0
在2010年10月26日,PCI DSS 釋出了版本2.0。這裡有一些需要強調的。
- 132處更新,2處新增,其餘的都是澄清說明和附加準則。
- 增加了更多有關虛擬化的準則和它們對PCI的影響。
- 亞馬遜網路服務中心(Amazon web services,AWS)現在是符合PCI 1級規範的資料中心。
細節
既然已經知道了所有一切有關PCI的知識,那麼就讓我們深入細節吧。我被問到的最常見問題是“有什麼最簡單的方法稱為PCI認證商戶?”。這裡就有我可以告訴大家的。
第一道關卡是如果要幫客戶使用信用卡做交易,應避免處理客戶的信用卡資料。今後隨著Braintree和stripe這樣的公司出現,這會變得非常容易。在可以用這些解決方案之前的很多年,唯一能做到這點的方法是用醜陋的支付網頁host信用卡閘道器,但是這不能很好的整合,也能難整合應用程式,所以很多人並不用這個方法。
現在沒有任何藉口了,讓信用卡處理器處理所有信用卡資料吧,這會讓生活更加輕鬆。如果想知道有多輕鬆,請訪問PCI security standards官網,下載SAQ A 和SAQ C文件。你會發現SAQ A非常容易,讓你少了很多麻煩。
雖然Briantree和stripe公司的解決方案很牛,但它們不能解決所有問題。近年來,隨著手機應用程式的使用越來越普遍,如何通過API來接收信用卡資料已成為了一個常見問題。如果基於某些理由不能使用其他解決方案中的辦法,可以使用Akamai公司的Edge Tokenization,它不僅適用於API,也適用於基於網路支付的表單。雖然很昂貴,但是如果已經使用了Akamai公司其他一些解決方案,那麼這對你來說也不是個大問題。
如果看完上述所說的所有辦法之後,依舊需要/想要通過自己的伺服器來驗收信用卡資料,那麼你需要知道一些其它事情。比如,下列這份大多數人都會犯的常見錯誤列表。
PCI常見錯誤
這裡有一份大多數人都會犯的常見錯誤列表。之所以在這裡羅列它們,只是為了在還不是太晚的時候讓你能夠意識到這些錯誤,如果遺漏了什麼,請聯絡我讓我知曉。
在空白文字中儲存信用卡資訊
理想化情況下,不應該儲存信用卡資訊。但是如果不得不這麼做,應該常常加密資料。這樣如果有人拿到了資料,他們也只有花更多精力才能看到資料。
沒有改掉預設密碼
我經常對此感到驚訝:人們所使用的密碼安全性非常低而且很多次開始登入時,大家依舊在使用第一次給他們時的密碼。那就是為什麼要一次性生成一個密碼並確保它安全。這樣的話,如果人們不更改被告知的密碼,至少在剛開始時候,這個密碼是安全的。
如今在市場上真的有很多相當不錯的密碼管理工具,我可以推薦其中的一個。我喜歡用的一個是1password。
從伺服器上去除所有不需要的程式
有很多理由可以告訴你:為什麼要在不想使用計算機上的程式/軟體時,去除它們。第一個理由是:它們會使計算機空間變少,而且即使沒有執行它們也會佔據處理器和RAM空間。一個執行更快的系統總是好的。第二個理由是:可以不必維護那些不想使用的軟體程式安全補丁。這樣的話,當拿來一臺新的線上伺服器時,首先要做的是去除所有不想用的東西,如果後來想用,可以在之後再把它們加回到系統中去。
使用防火牆
應該經常使用防火牆。只要使用它並從不關閉它,不管是硬體防火牆還是軟體防火牆都無所謂。在我的某些生產系統中,我執行一個硬體防火牆來保護我的私人網路,同時又在每個系統上執行一個軟體防火牆。某些人會認為這樣做是多此一舉,但我寧願更加安全點,也比出了事情才遺憾要好。
執行防火牆只是其中一部分,還要知道如何和為什麼安裝防火牆。也應該經常記錄埠開啟情況,並知道為什麼要開啟。這在之後審計時,審計人員想知道哪個埠開著,以及開這個埠的理由是什麼的時候,會非常有幫助。
應該每季度對防火牆進行一次審查,確保它們和所記錄的情況一致,並要清楚任何以前開啟過的埠是否依舊需要開啟。隨著時間流逝、系統發生變化或某些時候要去除某個不再需要的服務時,你也需要關閉埠。
也可以使用像CloudFlare這樣的服務,來保護網站免於一系列諸如垃圾郵件傳送、SQL隱碼攻擊和DDOS這樣的線上攻擊,這很容易安裝,而且要儘量使你的程式碼變更最小化。
編寫劣質網站程式碼
如果正在編寫Web應用程式程式碼的程式設計師們很粗心大意,並且不知道他們自己正在幹嘛,他們可能會寫出導致SQL隱碼攻擊和其他弱點的糟糕程式碼。
跨站點指令碼攻擊(Cross Site Scripting,XSS)如今正在成為一種越來越普遍使用的攻擊網站方法,所以對此你也要小心點。
要保證經常執行程式碼審查工作,並在將程式碼投入生產環境之前,對應用程式進行滲透測試/(滲透測試,Penetration Testing。作為網路安全服務體系中的一種新技術,是在實際網路環境下,由高素質的測試人員發起的,經過授權的高階安全檢測行為。——譯者注)
缺少監控和日誌記錄
令人驚訝的是很多公司並不監控自己的系統或應用程式,這就如同他們正在閉著眼睛跑步一樣,當情況正在變的糟糕時,他們根本沒有意識到糟糕情況發生,直到客戶告訴他們才意識到。應該儘可能地進行更多的監控和日誌記錄工作,這樣就能在任何時候知道任何系統上正在發生的事情。如果系統執行良好時,不做日誌記錄,那麼當某些情況開始變的糟糕時,你不會意識到這些看似和它們良好時一樣的糟糕情況。 這裡有一份工具列表能幫助你進行日誌記錄和監控。
- Pingdom是個網站監控工具。當站點出問題的時候,能告知一切情況。
- Nagios提供完整的伺服器、交換機、應用程式和服務監控提醒。
- Cacti是套完整的網路圖形化解決方案。被設計成用來駕馭RRDTool資料儲存和圖形化功能的強大威力。
- Sentry開源實時記錄事件日誌的聚合平臺。
- Loggly日誌管理雲服務端,集中化的記錄搜尋分析、時間序列資料日誌。
- graphite可擴充套件的實時圖形化伺服器。
- collectd是個間歇性收集系統效能統計資料的後臺程式,並用多種方式提供值儲存機制,如RRD檔案。
- monit可簡單和積極主動的監控Linux/Unix系統、網路和雲伺服器。
- muninMunin是個有助於分析資源趨勢的網路資源監控工具。
- New Relic是唯一一個可以精確定位和解決Ruby、Java、.NET、PHP和Python應用程式效能問題的工具。
- Pager Duty為Nagios、Zenoss、Munin、Monit和更多其他IT監控工具進行電話&簡訊提醒和待命安排。
缺少安全補丁
定期安排在所有的系統上安裝所有安全補丁,對你來說非常重要。一個看似沒道理但令人驚訝的現象是很多人或公司並不這樣做。
也應該為任何正在使用的產品訂閱所有安全提醒電子郵件列表。同時也要注意下列網站。一旦收到某個潛在問題通知,就能在它影響你之前修復它。
- http://www.us-cert.gov/cas/
- http://seclists.org/
- http://www.sans.org/newsletters/
在支付頁面沒有使用SSL
這是另外一個沒道理但時不時發生的現象,應該在web應用程式裡新增程式碼來檢查SSL是否已保證服務於支付頁面。如果不是,請重定向到有SSL版本的頁面。
做到這點的一個簡單方式是:讓SSL在任何時候都服務於整個站點,然後把web伺服器80(http)埠簡單的重定向到443(https)埠。這就能保證在任何時候所有的資料傳輸情況都能被SSL服務。
記錄支付資訊日誌
我所見到的最常見錯誤之一是:某些人設定他們的日誌管理工具能把支付表單中的資料列印到日誌檔案中去。出於除錯目的這是非常好的,但是對PCI來說卻很糟糕。應該經常在記錄請求日誌之前,把重要的資訊從請求中剝離出去。也可以把信用卡卡號替換成*號加後4位號碼來達到同樣的除錯結果。
另外一個與之相似的常見錯誤是:當發生某個錯誤,email給開發人員時,把所有的資料都發給他們。如果你也這麼做,首先要確保已剝離了信用卡資訊,否則某人的信用卡資訊說不定現在已經被email傳送到全世界各地了,這完全是不對的啊。
能儲存的信用卡資料
很重要的一點是永遠不儲存信用卡資料到資料庫中,即使已加密資料。很不值得為此被麻煩、冒風險和花費處理外部審計的成本。但如果一定要堅持這麼做,這裡有一些需要知道的事情。
如果基於某些理由,對我的建議置若罔聞,並且不管如何都要儲存信用卡資料。這裡有張小圖顯示了哪些資料可以被儲存。而不管它是否被加密。
- 根據3.3:顯示時掩蓋卡號(信用卡卡號頭6位和後4位號碼是最多可顯示的號碼)。這意味著可以像*****1234 Visa那樣替換真實的信用卡卡號。如今這樣做非常普遍。
- 根據3.4:使用下列任何一種方法,使卡號不管被儲存到哪裡,都不可讀:(包括行動式數字媒介裝置、備份媒介裝置和日誌檔案)
- 基於強密碼方式的單向雜湊法(必需雜湊整個卡號)[可使用諸如安全雜湊演算法(Secure Hash Algorithm,SHA)這樣基於強密碼方式的單向雜湊函式,使持卡人資料不可讀。雜湊函式不需要檢索原始卡號號碼(因為單向雜湊法是個不可逆的過程)。為了建立複雜的彩虹表(彩虹表就是一個龐大的、針對各種可能的字母組合預先計算好的雜湊值的集合——譯者注),推薦但不強制要求在卡號之外還輸入一個加鹽值(來源於MD5演算法。因為MD5演算法本身是不可逆的,為了加強MD5的安全性從而加入的新的演算法部分即加鹽值——譯者注)到雜湊函式中去。]
- 截值法(雜湊法不能用來替換卡號被截斷的部分)。
- 索引令牌和pad值(必需安全儲存pad值)。
- 使用強加密有關鍵值管理的過程和流程的方法。
令牌標記
如果要儲存信用卡資訊,最好的方法是使用令牌標記(tokenization)服務來代替自己儲存資訊。把信用卡資訊儲存到他們的系統中去。他們會給你一個唯一的令牌以供在未來交易中用它代替信用卡進行交易。如今這種型別的服務也非常普遍,只需問你的信用卡髮卡商是否也有這樣的服務就行。這裡有一些提供這種型別服務的信用卡髮卡商公司資訊。
資料中心
當遵照PCI規範進行交易時,需要擔心全部東西。不僅是應用程式,也有安裝應用程式的伺服器、伺服器連線的網路和伺服器所“居住”的資料中心。首先要做的事情是聯絡主機提供商瞭解他們是否遵照PCI規範。如果他們是的話,要向他們要一份有你的記錄情況的PCI檔案拷貝(之後或許會需要)。主機提供商們經常在他們的官網網頁上“吹噓”自己遵照PCI規範,所以這常常也是一個好的開始。
主機提供商公司規模越小,則遵照PCI規範進行交易的可能性越小。如果你只參與了一個共享主機計劃,每個月只需付20美金,那麼極有可能沒有遵照PCI規範。或許你運氣好,但是我對此很懷疑。如果主機提供商公司是PAAS或是一家雲伺服器提供商公司,那你也極有可能沒那麼幸運了。
提供雲伺服器的主機供應商
亞馬遜網路服務中心(AWS)最近已經讓他們的資料中心滿足了PCI規範,但需要重點注意的是僅僅因為資料中心遵照規範並不說明你的應用程式也是這樣。如果你把應用程式放在EC2,接受那些EC2例項所處理的信用卡資料,那麼需要確保除了其他東西之外,還有個入侵檢測系統(Intrusion Detection System,IDS)(入侵檢測系統是一種對網路傳輸進行即時監視,在發現可疑傳輸時發出警報或者採取主動反應措施的網路安全裝置——譯者注)。所有好的IDS系統都是基於硬體的。並且有專人在任何時候監控資料傳輸情況。在AWS不能安裝這些系統,所以需要依賴一套基於解決方案的軟體,而這並不好,並且對網路增加了額外的複雜性。
RackSpace公司提供hybrid cloud hosting配置服務,能讓你有硬體防火牆、IDS、負載均衡、雲網路伺服器和硬體資料庫伺服器。但是即使這樣的配置服務,也沒有遵照PCI規範,至少我還不能讓RackSpace告訴我它遵照了PCI規範。
其他雲伺服器供應商可能會提供一套完整的符合PCI規範的解決方案,但我猜他們會讓你花更多的錢。如果你知道有這麼一家,請讓我知曉。我會把這家公司資訊更新到這裡。Terremark公司極有可能就是這麼一家公司。
安全掃描
PCI認證中的一個關鍵部分是要求有第三方安全掃描公司。基本上,你不得不請一家已獲得認證或批准的安全掃描公司定期掃描網路、伺服器和應用程式,如果他們發現任何問題,你需要修復這些問題,修復之後他們會再次掃描,直到已通過掃描。一旦通過,他們會給你一份認證合格證照,你可以把它加入到你的PCI檔案中去。
以前我曾經請過一家叫ControlScan的公司,也請過Qualys公司。但我相信還有很多其他這樣的公司。請為你挑選一家看起來最好的公司。這裡是一個連結PCI approved scanning vendors,羅列了一份PCI獲批掃描承包商公司資訊列表。
入侵檢測系統
入侵檢測系統(IDS)基本上位於網路前端,觀察所有進入網路的資料傳輸情況。這看起來,如果它發現有任何異常情況或有人嘗試使用已知網路攻擊手段攻擊網路和其它某些情況,它都會讓你知道。這些系統都有基於解決方案的硬體和軟體。價格也從免費到一個月上千美金不等。互相之間也各有不同特點和功能,所以最好挑一個你需要的,並易於維護的系統。
我曾用過AlertLogic公司基於IDS的硬體,效果蠻好的。這個公司有一群隨時待命專門監控裝置的員工。如果有什麼事情發生,他們會去檢查裝置並根據情況採取相應措施。
雜湊破解信用卡號碼
這裡有個很好的例子說明為什麼雜湊破解信用卡號碼不是個好主意。我正在瀏覽下列這兩個連線中的有關內容,
- http://en.oreilly.com/rails2011/public/schedule/detail/19466
- http://www.integrigy.com/security-resources/whitepapers/Integrigy_Hashing_Credit_Card_Numbers_Unsafe_Practices.pdf
僅僅因為遵照了PCI規則並不意味著萬事無憂,你依舊不得不運用常識。
PCI DSS 3.4小節[pdf]: 使用以下任何一種方法,使卡號不管被最小程度的儲存到哪裡,都不可讀:強單向雜湊函式(雜湊索引)。 使用以下任何一種方法驗證資料已不可讀:如SHA-1這樣的單向雜湊法(雜湊索引)。
基本大意是你可以儲存信用卡卡號頭6位號碼(BIN),也可儲存信用卡卡號後4位號碼。信用卡卡號長度介於13到16位,最後1位號碼是校驗位(Luhn 校驗演算法)。
讓我們看看,破解出這張卡號為4012888888881881的信用卡卡號號碼有多難。
如果我們不知道這張卡的任何資訊,從全16位開始算,即有10的16次方(10^16)或10,000,000,000,000,000(10千兆)種可能的卡號號碼。
既然正在儲存信用卡型別,我們知道這是張visa卡。所有Visa信用卡都是以“4”開頭的。這意味著可能是4XXXXXXXXXXXXXXX或有4,000,000,000,000,000(4千兆)種可能的卡號號碼。只減除了一半以上可能的卡號號碼。
如果我們能儲存bin(卡號前6位號碼)和後4位號碼,那麼會是這樣的:401288******1881或1,000,000(100萬)種可能的卡號號碼。
開始寫一個簡單的破解程式來試試運氣。(程式用Ruby編寫)
程式碼 執行一下
如果只是使用SHA-1雜湊法,這段程式用了5.3秒就破解了雜湊碼。可以使它破解的更快,只要在執行雜湊法之前,對卡號號碼做一次luhn校驗。如果luhn校驗失敗,那麼就知道卡號號碼無效了,也就沒必要執行雜湊法了。既然雜湊函式執行的比luhn校驗慢,這就說明luhn校驗能加快執行速度。
彩虹表和加鹽值
由於信用卡卡號號碼是個有限的數字,那麼可以預先計算出10千兆種可能的卡號號碼中的每個值它的雜湊碼,然後將這些雜湊碼儲存在一個可查詢的表格中。當需要破解某張信用卡卡號雜湊碼的時候,所有需要做的事情就是查到該張信用卡卡號雜湊碼,這樣就能很快的破解出這張卡卡號。像這樣儲存所有已知值的表格叫做彩虹表(Rainbow table)。
理想情況下,如果想雜湊破解某張信用卡,不要使用SHA-1或MD5方法,而是使用SHA更新版本的方法:SHA-256或再之上的版本方法。同時也要使用加鹽值(salt)。加鹽值基本上是雜湊破解時經常使用的第二唯一值,通常只要得到信用卡號碼就能生成一個不同的加鹽值。
既然生成彩虹表時,沒有加鹽值,彩虹表就不管用。這就增加了額外的安全性。確保加鹽值不被丟失,否則不得不重頭再來。把加鹽值看作密碼並保證它安全。
真的需要擔心被黑客攻擊嗎?
這裡有一份最近受到黑客攻擊的公司資訊簡單列表。如果他們都能被黑客攻擊,那麼你呢?
- TJ Maxx
- Bank of America
- Citigroup
- BJ's wholesale club
- Hotels.com
- LexisNexis
- Polo Ralph Lauren
- Wachovoa
- Heartland Payment Systems
- Hannaford
如果被黑客攻擊了,會發生什麼?
- 被禁止接受信用卡交易。
- 名譽損失和顧客流失。
- 每次事故高達50萬美金的罰款。
- 法律問題(可能會受到控告)。
如果權益受到侵害,該怎麼辦?
在發生安全事故的事件中,商戶必需採取以下緊急措施:
- 控制和限制資訊曝光。對24小時內有懷疑或已確認會危及賬戶資訊的損失或劫持,進行徹底的調查。
- 提醒所有有必要提醒的各方機構。要確認提醒:
- 商戶帳號提供商。
- Visa金融欺詐控制小組。電話:(650) 432-2978
- FBI本地辦公室。
- U.S.祕密服務機構(如果已危及Visa支付資料)。
- 24小時內,向Visa金融欺詐控制小組提供被危及的Visa賬戶資訊。
- 在報告危害後的4個工作日之內,向Visa提供一份事故報告。
相關連結:
Discover Financial Services PCI pages
MasterCard Worldwide PCI pages
原文來自: http://kencochrane.net/blog/2012/01/developers-guide-to-pci-compliant-web-applications/
The Developers Guide to PCI Compliant Web applications
iTran樂譯
去iTran樂譯參加活動,讀好文章!
相關文章
- IBM P670更換PCI卡IBM
- PCI-E介面知識科普 顯示卡PCI/AGP/PCI-E介面有什麼區別?
- IOMMU是如何劃分PCI device group的?dev
- 關於3650M4安裝HBA卡PCI報警解決方法
- Linux下PCI轉串列埠卡驅動安裝方法Linux串列埠
- Linux下PCI轉串列埠卡及USB轉串列埠Linux串列埠
- Google Web應用開發指南第一章:什麼是Web應用?GoWeb
- PCI-Express-Technology(四)Express
- RTX下IK220計數卡的PCI示例程式碼,自己分析用
- PCI裝置的地址空間 【轉】
- PCI-5565系列反射記憶體卡 反射記憶體交換機反射記憶體
- Hi3511 Hi3512_PCI開發參考
- Web開發必備的20個速記卡Web
- Delphi之三匯模擬語音卡(SHT-8B/PCI/FAX)可複用原始碼原始碼
- 探索 PCI 轉 PMC 載板轉接卡:連線不同介面的橋樑
- 安裝XP時PCI.SYS報錯
- 使用libvirt配置pci bus的numa親和性
- Web開發人員必備的18個iPhone應用程式WebiPhone
- 【原創】Linux PCI驅動框架分析(一)Linux框架
- 【原創】Linux PCI驅動框架分析(二)Linux框架
- 開發Web應用Web
- PCI-DSS(V3.2)學習筆記(二)筆記
- rss在web開發過程中的全方位應用Web
- 關於WEB應用程式的列印元件開發初探 (轉)Web元件
- WEB應用開發中的ServletWebServlet
- 瞭解PCI Express的Posted傳輸與Non-Posted傳輸Express
- 關於企業級應用和web開發的區別Web
- 微信支付開發避坑指南
- Node助力Web應用開發——在新的開發平臺,打造高效能Web應用Web
- Web應用的元件化開發(一)Web元件化
- Web應用的元件化開發(二)Web元件化
- ExtJS Web應用程式開發指南(針對Ext JS 4.0更新)JSWeb
- Google Web應用開發指南第二章:互動設計GoWeb
- SATA介面已死:PCI-E SSD將成市場主流
- JavaWeb開發必過關-Servlet學習(一)JavaWebServlet
- 使用Taro開發鴻蒙原生應用——快速上手,鴻蒙應用開發指南鴻蒙
- 使用 Taro 開發鴻蒙原生應用 —— 快速上手,鴻蒙應用開發指南鴻蒙
- 支付寶線上支付介面開發教程與總結