it-swarm-vi.com

Thuyết phục công ty không lưu trữ số thẻ tín dụng trong ứng dụng web của chúng tôi

Công ty tôi làm việc cần một hệ thống để thực hiện tính phí thẻ tín dụng hàng tháng vào tài khoản của khách hàng. Khách hàng sẽ có thể cập nhật thông tin thẻ tín dụng của mình từ giao diện trực tuyến được viết bằng PHP (sẽ được trình bày qua HTTP qua SSL). Các khoản phí hàng tháng sẽ được chạy thủ công thông qua quản trị viên được bảo vệ bằng mật khẩu khu vực của cùng một giao diện, về cơ bản sẽ tương đương với một lệnh gọi hàng loạt đến API của Authorize.Net.

Đồng nghiệp của tôi muốn lưu trữ thông tin thẻ tín dụng (được mã hóa) trong cơ sở dữ liệu MySQL. Họ dự định mã hóa số thẻ tín dụng bằng phần mở rộng mcrypt của PHP , có lẽ sử dụng Rijndael/AES hoặc Twofish. Chủ đề của quản lý khóa đã được trình bày, nhưng hai tùy chọn sau đã được đề cập:

  1. lưu trữ khóa trong cơ sở dữ liệu, với một khóa riêng cho mỗi lần nhập thẻ tín dụng; hoặc là

  2. lưu trữ một khóa mã hóa duy nhất cho tất cả các mục nhập thẻ tín dụng trong tệp PHP dưới dạng biến (tương tự như cách PHP ứng dụng như WordPress và MediaWiki lưu trữ thông tin cơ sở dữ liệu).

Làm cách nào tôi có thể thuyết phục họ không đi tuyến đường này? Chúng tôi sẽ sử dụng Authorize.net để xử lý thanh toán, vì vậy tôi đã đề cập Trình quản lý thông tin khách hàng dịch vụ thay thế cho việc lưu trữ thông tin thẻ tín dụng của chúng tôi. Tuy nhiên, tôi không biết rõ chủ đề này để đưa ra một lập luận thuyết phục (lập luận của tôi là "không ai trong chúng tôi là chuyên gia bảo mật" và "Tôi sẽ không cảm thấy thoải mái với một công ty lưu trữ thông tin thẻ tín dụng của mình theo cách này").

Nếu tôi không thể thuyết phục họ sử dụng dịch vụ của bên thứ 3 như Trình quản lý thông tin khách hàng, tôi nên giữ gì để giữ thông tin thẻ tín dụng của khách hàng an toàn? Cụ thể, tôi nên quản lý khóa mã hóa như thế nào? Nên có một khóa mã hóa riêng cho mỗi mục nhập của khách hàng? Tôi có thể lưu trữ khóa ở đâu để tôi có thể giải mã thông tin thẻ tín dụng trước khi gửi giao dịch tới Authorize.Net? Hai tùy chọn được đề cập ở trên dường như không hợp lý với tôi (nhưng một lần nữa, tôi không biết rõ về chủ đề này để đưa ra một lập luận thuyết phục chống lại một trong hai).


Cập nhật : Tôi đã tìm thấy ai đó trong công ty quen thuộc với PCI DSS tuân thủ, vì vậy tôi đang làm việc với anh ấy để thực hiện chắc chắn điều này được thực hiện đúng. Tuy nhiên, tôi vẫn sẽ đánh giá cao câu trả lời cho các câu hỏi của tôi ở trên (cả hai để cải thiện kiến ​​thức của tôi và giúp đỡ những người khác trong tình huống tương tự).

Cập nhật 2 : Thành công! Một nhà phát triển khác đã ngồi xuống và đọc hướng dẫn PCI DSS và quyết định rằng cuối cùng chúng tôi nên lưu trữ thông tin. Chúng tôi sẽ sử dụng Authorize.Net's Trình quản lý thông tin khách hàng dịch vụ.

38
M8R-53mg86

Lưu trữ số thẻ có nghĩa là bạn phải tuân thủ các yêu cầu của PCI-DSS hoặc bạn có nguy cơ bị phạt và vi phạm hợp đồng tài khoản thương gia của mình. PCI-DSS có một loạt các yêu cầu khổng lồ - một số hợp lý, một số vấn đề hữu ích, một số hữu ích đáng nghi ngờ - và chi phí tuân thủ nó, và xác nhận rằng bạn đã tuân thủ nó, có thể rất cao.

Tải xuống chuẩn PCI-DSS 2. và sợ.

Đặc biệt, cả hai cách tiếp cận được đề xuất đều không tuân thủ PCI-DSS. Khóa không được lưu trữ không được bảo vệ hoặc ở cùng một nơi với dữ liệu chủ thẻ mà họ bảo vệ.

Nếu bạn phải triển khai nội bộ này, bạn cần cách ly các thành phần chạm vào số thẻ với mọi thứ khác, để PCI-DSS chỉ áp dụng cho một số hệ thống hạn chế. Nhìn vào các giải pháp mã thông báo để giúp bạn giữ cho dữ liệu chủ thẻ của bạn tiếp xúc ở mức tối thiểu. Nếu bạn không làm đúng, bạn có thể dễ dàng thả tất cả các máy chủ của mình (hoặc thậm chí tất cả các máy tính để bàn của công ty!) Vào phạm vi PCI, tại đó việc tuân thủ trở nên khó thực hiện.

Authorize.net cung cấp dịch vụ thanh toán định kỳ tự động. Đối với tình yêu của sự tỉnh táo, sử dụng đó.

33
bobince

"Không ai trong chúng tôi là chuyên gia bảo mật" và "Tôi sẽ không cảm thấy thoải mái với một công ty lưu trữ thông tin thẻ tín dụng của mình theo cách này" là những lý lẽ hoàn toàn hợp lệ. Từ góc độ kỹ thuật (về giá trị), họ nên để kết thúc cuộc thảo luận. Nhưng nếu bạn đang tranh cãi với những người không phải là chuyên gia bảo mật, họ có thể không ở vị trí để nhận ra những lý lẽ tốt.

Vì vậy, nếu bạn thấy rằng tranh luận về công đức không đưa bạn đến bất cứ nơi nào, hãy rút ra Sledgehammer of Tuân thủ (có +20 thiệt hại chống lại quan chức). Đặc biệt, nhắc nhở họ về PCI DSS. Hỏi họ xem họ đã bỏ ra chi phí để đạt được PCI DSS. Yêu cầu họ phân tích lợi ích chi phí về việc doanh thu này sẽ cung cấp thêm bao nhiêu (thông thường, câu trả lời là: 0 ) và chi phí cho doanh nghiệp sẽ là bao nhiêu (thông thường, câu trả lời là: lớn). Trong hầu hết các tình huống, đó sẽ là trò chơi kết thúc.

Hoặc, ít nhất nó nên kết thúc cuộc thảo luận. Nếu không, hãy nói chuyện với người quản lý của bạn, vì đây cuối cùng là một quyết định kinh doanh và họ sẽ nhanh chóng nhận ra cuộc gọi đúng.

Và nếu người quản lý của bạn không hiểu điều đó - tốt, tất cả những gì tôi có thể đề xuất là: có người quản lý mới. Có lẽ đã đến lúc cập nhật sơ yếu lý lịch của bạn.

28
D.W.

Có vẻ như công ty của bạn đã trải qua PCI DSS đánh giá tại chỗ trước đó hoặc thậm chí đã cố gắng trả lời tất cả các câu hỏi trong SAQ D. Đối với hầu hết mọi công ty có, họ đang tìm cách để loại bỏ dữ liệu chủ thẻ và hy vọng rằng họ không quá tốn kém để làm như vậy. Nếu bạn đang ở thời điểm chưa thực hiện được giải pháp, bạn hoàn toàn nên lưu trữ dữ liệu của mình Authorize.net hoặc bên thứ 3 khác.

Lập luận tốt nhất bạn có thể đưa ra cho đồng nghiệp là giải thích mức độ rắc rối của PCI và mức độ rắc rối này giảm đi bao nhiêu nếu bạn không tự lưu trữ dữ liệu chủ thẻ. Duy trì tuân thủ PCI là một công việc toàn thời gian. Nếu bạn đang lưu trữ dữ liệu chủ thẻ, có rất nhiều yêu cầu khác mà bạn phải đáp ứng để duy trì sự tuân thủ (PCI DSS SAQ D dài gấp đôi SAQ C). Cách đơn giản nhất để đi. Tôi thực sự thậm chí sẽ không xem xét việc lưu trữ dữ liệu của mình.

7
freb

Hầu hết các ông chủ/đồng nghiệp không nhất thiết phải hiểu tất cả các vấn đề 'kỹ thuật' mà bạn có thể trình bày chúng.

Do đó, bạn cần giải quyết chúng trong một lĩnh vực mà chúng hoàn toàn có thể hiểu - chi phí/tiền.

Một trong những điều mà tôi thấy hữu ích khi giải thích điều này là nếu bạn bị hack và thông tin thẻ tín dụng bị đánh cắp, họ sẽ phải chịu trách nhiệm, không chỉ về tiền phạt mà còn về chi phí cấp lại thẻ tín dụng mới.

Ví dụ: nếu công ty của bạn có 100.000 số thẻ tín dụng, họ sẽ phải trả một triệu đô la cho việc thay thế các thẻ đó TRƯỚC KHI họ phải trả bất kỳ khoản tiền phạt nào, v.v ... và nhân tiện, CFO có thể bị tống giam nếu họ không tuân thủ PCI)

Giống như họ có bảo hiểm cho tài sản của họ

4
pzirkind