Một kiểm toán viên bảo mật cho các máy chủ của chúng tôi đã yêu cầu như sau trong vòng hai tuần:

• Danh sách tên người dùng hiện tại và mật khẩu văn bản đơn giản cho tất cả tài khoản người dùng trên tất cả các máy chủ
• Một danh sách tất cả các thay đổi mật khẩu trong sáu tháng qua, một lần nữa ở dạng văn bản đơn giản
• Danh sách "mọi tệp được thêm vào máy chủ từ các thiết bị từ xa" trong sáu tháng qua
• Khóa công khai và khóa riêng của bất kỳ khóa SSH nào
• Một email được gửi cho anh ta mỗi khi người dùng thay đổi mật khẩu của họ, chứa mật khẩu văn bản đơn giản

Chúng tôi đang chạy các hộp Red Hat Linux 5/6 và CentOS 5 với xác thực LDAP.

Theo như tôi biết, mọi thứ trong danh sách đó đều không thể hoặc cực kỳ khó lấy, nhưng nếu tôi không cung cấp thông tin này, chúng tôi sẽ phải đối mặt với việc mất quyền truy cập vào nền tảng thanh toán của mình và mất thu nhập trong giai đoạn chuyển tiếp khi chúng tôi chuyển sang dịch vụ mới. Bất kỳ đề xuất cho làm thế nào tôi có thể giải quyết hoặc giả mạo thông tin này?

Cách duy nhất tôi có thể nghĩ để có được tất cả các mật khẩu văn bản đơn giản, là yêu cầu mọi người đặt lại mật khẩu của họ và ghi chú lại những gì họ đặt mật khẩu. Điều đó không giải quyết được vấn đề thay đổi mật khẩu trong sáu tháng qua, bởi vì tôi không thể đăng nhập hồi tố loại đó, tương tự với việc ghi nhật ký tất cả các tệp từ xa.

Có được tất cả các khóa SSH công khai và riêng tư (mặc dù gây phiền nhiễu), vì chúng tôi chỉ có một vài người dùng và máy tính. Trừ khi tôi đã bỏ lỡ một cách dễ dàng hơn để làm điều này?

Tôi đã giải thích với anh ấy nhiều lần rằng những điều anh ấy yêu cầu là không thể. Đáp lại những lo lắng của tôi, anh ấy đã trả lời email sau:

Tôi có hơn 10 năm kinh nghiệm trong kiểm toán bảo mật và hiểu biết đầy đủ về các phương pháp bảo mật, vì vậy tôi khuyên bạn nên kiểm tra sự thật của mình về những gì có thể và không thể thực hiện được. Bạn nói rằng không có công ty nào có thể có thông tin này nhưng tôi đã thực hiện hàng trăm cuộc kiểm toán trong đó thông tin này đã có sẵn. Tất cả các khách hàng [nhà cung cấp xử lý thẻ tín dụng chung] được yêu cầu tuân thủ các chính sách bảo mật mới của chúng tôi và việc kiểm toán này nhằm đảm bảo các chính sách đó đã được thực hiện * một cách chính xác.

* "Chính sách bảo mật mới" đã được giới thiệu hai tuần trước cuộc kiểm toán của chúng tôi và việc ghi nhật ký lịch sử sáu tháng là không bắt buộc trước khi thay đổi chính sách.

Tóm lại, tôi cần;

• Một cách để "giả" thay đổi mật khẩu trong sáu tháng và làm cho nó có vẻ hợp lệ
• Một cách để "giả" sáu tháng chuyển tập tin trong nước
• Một cách dễ dàng để thu thập tất cả các khóa riêng và công khai SSH đang được sử dụng

Nếu chúng tôi không thực hiện kiểm toán bảo mật, chúng tôi sẽ mất quyền truy cập vào nền tảng xử lý thẻ của chúng tôi (một phần quan trọng trong hệ thống của chúng tôi) và sẽ mất hai tuần để chuyển đi nơi khác. Làm thế nào tôi bị lừa?

Cập nhật 1 (Thứ bảy 23)

Cảm ơn tất cả các câu trả lời của bạn, Tôi cảm thấy nhẹ nhõm khi biết đây không phải là thông lệ tiêu chuẩn.

Tôi hiện đang lên kế hoạch trả lời email của mình để anh ấy giải thích tình hình. Như nhiều bạn đã chỉ ra, chúng tôi phải tuân thủ PCI, trong đó tuyên bố rõ ràng rằng chúng tôi không nên có bất kỳ cách nào để truy cập mật khẩu văn bản đơn giản. Tôi sẽ gửi email khi tôi viết xong. Thật không may, tôi không nghĩ rằng anh ta chỉ kiểm tra chúng tôi; những điều này nằm trong chính sách bảo mật chính thức của công ty. Tuy nhiên, tôi đã thiết lập các bánh xe chuyển động để di chuyển khỏi chúng và vào PayPal trong thời gian hiện tại.

Cập nhật 2 (Thứ bảy 23)

Đây là email tôi đã soạn thảo, có đề xuất nào cho công cụ thêm / xóa / thay đổi không?

Xin chào tên],

Thật không may, không có cách nào để chúng tôi cung cấp cho bạn một số thông tin được yêu cầu, chủ yếu là mật khẩu văn bản đơn giản, lịch sử mật khẩu, khóa SSH và nhật ký tệp từ xa. Những điều này không chỉ về mặt kỹ thuật là không thể, mà còn có thể cung cấp thông tin này sẽ vừa chống lại Tiêu chuẩn PCI, vừa vi phạm đạo luật bảo vệ dữ liệu.
Để trích dẫn các yêu cầu PCI,

8.4 Kết xuất tất cả mật khẩu không thể đọc được trong quá trình truyền và lưu trữ trên tất cả các thành phần hệ thống bằng mật mã mạnh.

Tôi có thể cung cấp cho bạn danh sách tên người dùng và mật khẩu băm được sử dụng trên hệ thống của chúng tôi, bản sao khóa công khai SSH và tệp máy chủ được ủy quyền (Điều này sẽ cung cấp cho bạn đủ thông tin để xác định số lượng người dùng duy nhất có thể kết nối với máy chủ của chúng tôi và mã hóa phương pháp được sử dụng), thông tin về các yêu cầu bảo mật mật khẩu và máy chủ LDAP của chúng tôi nhưng thông tin này có thể không được đưa ra khỏi trang web. Tôi thực sự khuyên bạn nên xem xét các yêu cầu kiểm toán của mình vì hiện tại chúng tôi không có cách nào để chúng tôi vượt qua cuộc kiểm toán này trong khi vẫn tuân thủ PCI và hành động Bảo vệ dữ liệu.

Trân trọng,
[tôi]

Tôi sẽ tham gia vào CTO của công ty và người quản lý tài khoản của chúng tôi và tôi hy vọng CTO có thể xác nhận thông tin này không có sẵn. Tôi cũng sẽ liên hệ với Hội đồng Tiêu chuẩn Bảo mật PCI để giải thích những gì anh ấy yêu cầu từ chúng tôi.

Cập nhật 3 (ngày 26)

Dưới đây là một số email chúng tôi trao đổi;

RE: email đầu tiên của tôi;

Như đã giải thích, thông tin này nên dễ dàng có sẵn trên bất kỳ hệ thống nào được duy trì tốt cho bất kỳ quản trị viên có thẩm quyền nào. Việc bạn không thể cung cấp thông tin này khiến tôi tin rằng bạn nhận thức được các lỗi bảo mật trong hệ thống của mình và không sẵn sàng tiết lộ chúng. Yêu cầu của chúng tôi phù hợp với hướng dẫn PCI và cả hai đều có thể được đáp ứng. Mật mã mạnh chỉ có nghĩa là mật khẩu phải được mã hóa trong khi người dùng nhập chúng nhưng sau đó chúng sẽ được chuyển sang định dạng có thể phục hồi để sử dụng sau.

Tôi thấy không có vấn đề bảo vệ dữ liệu cho các yêu cầu này, bảo vệ dữ liệu chỉ áp dụng cho người tiêu dùng không phải doanh nghiệp nên không có vấn đề gì với thông tin này.

Chỉ là, cái gì, tôi, không thể, thậm chí ...

"Mật mã mạnh chỉ có nghĩa là mật khẩu phải được mã hóa trong khi người dùng nhập chúng nhưng sau đó chúng nên được chuyển sang định dạng có thể phục hồi để sử dụng sau."

Tôi sẽ đóng khung nó và đặt nó lên tường của tôi.

Tôi đã chán ngấy việc ngoại giao và hướng dẫn anh ấy đến chủ đề này để cho anh ấy thấy phản ứng mà tôi nhận được:

Cung cấp thông tin này TRỰC TIẾP mâu thuẫn với một số yêu cầu của hướng dẫn PCI. Phần tôi trích dẫn thậm chí nói storage (ngụ ý nơi chúng tôi lưu trữ dữ liệu trên đĩa). Tôi đã bắt đầu một cuộc thảo luận trên ServerFault.com (Một cộng đồng trực tuyến dành cho các chuyên gia quản trị hệ thống) đã tạo ra một phản hồi lớn, tất cả đều cho thấy thông tin này không thể được cung cấp. Hãy đọc qua chính mình

https://serverfault.com/questions/293217/

Chúng tôi đã hoàn tất việc chuyển hệ thống của chúng tôi sang một nền tảng mới và sẽ hủy tài khoản của chúng tôi với bạn trong ngày hôm sau hoặc lâu hơn nhưng tôi muốn bạn nhận ra những yêu cầu này kỳ cục đến mức nào, và không có công ty nào thực hiện đúng hướng dẫn PCI, hoặc nên có thể cung cấp thông tin này. Tôi thực sự khuyên bạn nên nghĩ lại các yêu cầu bảo mật của mình vì không khách hàng nào của bạn có thể tuân thủ điều này.

(Tôi thực sự đã quên tôi đã gọi anh ta là một thằng ngốc trong tiêu đề, nhưng như đã đề cập, chúng tôi đã rời khỏi nền tảng của họ để không mất mát thực sự.)

Và trong phản ứng của mình, anh nói rằng dường như không ai trong số các bạn biết bạn đang nói về điều gì:

Tôi đọc chi tiết thông qua những phản hồi và bài viết gốc của bạn, tất cả những người phản hồi cần phải có được sự thật của họ. Tôi đã ở trong ngành này lâu hơn bất kỳ ai trên trang web đó, nhận được danh sách mật khẩu tài khoản người dùng là vô cùng cơ bản, đó là một trong những điều đầu tiên bạn làm khi tìm hiểu cách bảo mật hệ thống của mình và cần thiết cho hoạt động của bất kỳ bảo mật nào người phục vụ. Nếu bạn thực sự thiếu các kỹ năng để làm điều gì đó đơn giản thì tôi sẽ cho rằng bạn không cài đặt PCI trên máy chủ của mình vì có thể khôi phục thông tin này là một yêu cầu cơ bản của phần mềm. Khi xử lý một vấn đề nào đó như bảo mật, bạn không nên hỏi những câu hỏi này trên một diễn đàn công cộng nếu bạn không có kiến ​​thức cơ bản về cách thức hoạt động của nó.

Tôi cũng muốn đề nghị rằng mọi nỗ lực tiết lộ cho tôi hoặc [tên công ty] sẽ bị coi là bôi nhọ và hành động pháp lý phù hợp sẽ được thực hiện

Điểm ngu ngốc chính nếu bạn bỏ lỡ chúng:

• Anh ta là một kiểm toán viên an ninh lâu hơn bất kỳ ai khác ở đây (Anh ta đoán hoặc theo dõi bạn)
• Có thể nhận được danh sách mật khẩu trên hệ thống UNIX là 'cơ bản'
• PCI bây giờ là phần mềm
• Mọi người không nên sử dụng diễn đàn khi họ không chắc chắn về bảo mật
• Đưa thông tin thực tế (mà tôi có bằng chứng email) trực tuyến là phỉ báng

Xuất sắc.

PCI SSC đã trả lời và đang điều tra anh ta và công ty. Phần mềm của chúng tôi hiện đã chuyển sang PayPal để chúng tôi biết rằng nó an toàn. Tôi sẽ đợi PCI quay lại với tôi trước nhưng tôi hơi lo lắng rằng họ có thể đã sử dụng các thực tiễn bảo mật này trong nội bộ. Nếu vậy, tôi nghĩ đó là một mối quan tâm lớn đối với chúng tôi vì tất cả quá trình xử lý thẻ của chúng tôi đều chạy qua chúng. Nếu họ đang làm điều này trong nội bộ tôi nghĩ rằng điều duy nhất có trách nhiệm phải làm là thông báo cho khách hàng của chúng tôi.

Tôi hy vọng khi PCI nhận ra mức độ tệ hại của họ, họ sẽ điều tra toàn bộ công ty và hệ thống nhưng tôi không chắc chắn.

Vì vậy, bây giờ chúng tôi đã rời khỏi nền tảng của họ và giả sử rằng sẽ mất ít nhất vài ngày trước khi PCI quay lại với tôi, bạn có đề xuất sáng tạo nào về cách troll anh ấy một chút không? =)

Khi tôi đã nhận được thông quan từ người hợp pháp của mình (tôi rất nghi ngờ bất kỳ điều gì trong số này thực sự là phỉ báng nhưng tôi muốn kiểm tra lại) Tôi sẽ xuất bản tên công ty, tên và email của anh ấy và nếu bạn muốn bạn có thể liên hệ với anh ấy và giải thích tại sao bạn không hiểu những điều cơ bản về bảo mật Linux như làm thế nào để có được danh sách tất cả mật khẩu người dùng LDAP.

Cập nhật nhỏ:

"Người hợp pháp" của tôi đã đề nghị tiết lộ công ty có thể sẽ gây ra nhiều vấn đề hơn mức cần thiết. Tôi có thể nói mặc dù, đây không phải là nhà cung cấp chính, họ có ít hơn 100 khách hàng sử dụng dịch vụ này. Ban đầu, chúng tôi bắt đầu sử dụng chúng khi trang web còn nhỏ và chạy trên một ít VPS và chúng tôi không muốn trải qua tất cả nỗ lực để có được PCI (Chúng tôi thường chuyển hướng đến lối vào của họ, như PayPal Standard). Nhưng khi chúng tôi chuyển sang xử lý trực tiếp thẻ (bao gồm cả nhận PCI và theo lẽ thường), các nhà phát triển đã quyết định tiếp tục sử dụng cùng một công ty chỉ là một API khác nhau. Công ty có trụ sở tại khu vực Birmingham, Vương quốc Anh nên tôi rất nghi ngờ bất kỳ ai ở đây sẽ bị ảnh hưởng.

Đầu tiên, KHÔNG viết hoa. Anh ta không chỉ là một thằng ngốc mà còn sai lầm. Trên thực tế, việc tiết lộ thông tin này sẽ vi phạm tiêu chuẩn PCI (đó là điều tôi cho rằng kiểm toán là vì bộ xử lý thanh toán) cùng với mọi tiêu chuẩn khác ngoài kia và chỉ là lẽ thường. Nó cũng sẽ đưa công ty của bạn đến tất cả các loại nợ.

Điều tiếp theo tôi sẽ làm là gửi email cho sếp của bạn nói rằng anh ta cần phải tham gia tư vấn công ty để xác định sự tiếp xúc pháp lý mà công ty sẽ phải đối mặt bằng cách tiến hành hành động này.

Bit cuối cùng này là tùy thuộc vào bạn, nhưng tôi sẽ liên hệ với VISA với thông tin này và kéo trạng thái kiểm toán viên PCI của anh ấy.

Là một người đã làm thủ tục kiểm toán với Price Waterhouse Coopers cho một hợp đồng chính phủ được phân loại, tôi có thể đảm bảo với bạn, điều này hoàn toàn không có vấn đề gì và anh chàng này thật điên rồ.

Khi PwC muốn kiểm tra độ mạnh mật khẩu của chúng tôi, họ:

• Yêu cầu để xem các thuật toán sức mạnh mật khẩu của chúng tôi
• Chạy thử các đơn vị dựa trên thuật toán của chúng tôi để kiểm tra xem chúng có từ chối mật khẩu kém không
• Được yêu cầu xem các thuật toán mã hóa của chúng tôi để đảm bảo rằng chúng không thể bị đảo ngược hoặc không được mã hóa (ngay cả bởi các bảng cầu vồng), ngay cả bởi một người có quyền truy cập đầy đủ vào mọi khía cạnh của hệ thống
• Đã kiểm tra để thấy rằng mật khẩu trước đó đã được lưu trong bộ nhớ cache để đảm bảo rằng chúng không thể được sử dụng lại
• Yêu cầu chúng tôi cho phép (mà chúng tôi đã cấp) để họ cố gắng xâm nhập vào mạng và các hệ thống liên quan bằng cách sử dụng các kỹ thuật phi xã hội (những thứ như khai thác xss và không 0 ngày)

Nếu tôi thậm chí còn gợi ý rằng tôi có thể cho họ biết mật khẩu của người dùng trong 6 tháng qua, họ sẽ khiến chúng tôi ngừng hợp đồng ngay lập tức.

Nếu có thể cung cấp các yêu cầu này, bạn sẽ ngay lập tức thất bại trong mọi cuộc kiểm toán duy nhất có giá trị.

Cập nhật: Email phản hồi của bạn có vẻ tốt. Chuyên nghiệp hơn nhiều so với bất cứ điều gì tôi sẽ viết.

Thành thật mà nói, có vẻ như anh chàng này (kiểm toán viên) đang thiết lập bạn. Nếu bạn cung cấp cho anh ấy thông tin anh ấy yêu cầu, bạn đã chứng minh cho anh ấy thấy rằng bạn có thể được thiết kế xã hội để từ bỏ thông tin nội bộ quan trọng. Thất bại.

Tôi vừa phát hiện ra bạn đang ở Vương quốc Anh, điều đó có nghĩa là những gì anh ấy yêu cầu bạn làm là vi phạm luật (thực tế là Đạo luật bảo vệ dữ liệu). Tôi cũng ở Anh, làm việc cho một công ty lớn được kiểm toán chặt chẽ và biết luật pháp và các thông lệ chung quanh khu vực này. Tôi cũng là một công việc rất khó chịu, người sẽ vui vẻ kiềm chế anh chàng này cho bạn nếu bạn thích chỉ vì niềm vui của nó, hãy cho tôi biết nếu bạn muốn giúp đỡ ok.

Bạn đang được xã hội thiết kế. Hoặc là 'kiểm tra bạn' hoặc tin tặc giả làm kiểm toán viên để có được một số dữ liệu rất hữu ích.

Tôi thực sự lo ngại về việc OP thiếu kỹ năng giải quyết vấn đề đạo đức và cộng đồng lỗi máy chủ bỏ qua hành vi vi phạm đạo đức trắng trợn này.

Tóm lại, tôi cần;

• Một cách để 'giả' thay đổi mật khẩu sáu tháng và làm cho nó trông hợp lệ
• Một cách để 'giả' sáu tháng chuyển tập tin trong nước

Hãy để tôi rõ ràng về hai điểm:

1. Không bao giờ thích hợp để làm sai lệch dữ liệu trong quá trình kinh doanh bình thường.
2. Bạn không bao giờ nên tiết lộ loại thông tin này cho bất cứ ai. Không bao giờ.

Nó không phải là công việc của bạn để làm sai lệch hồ sơ. Công việc của bạn là đảm bảo rằng mọi hồ sơ cần thiết đều có sẵn, chính xác và an toàn.

Cộng đồng tại Server Fault phải xử lý các loại câu hỏi này vì trang web stackoverflow xử lý các câu hỏi "bài tập về nhà". Bạn không thể giải quyết những vấn đề này chỉ bằng một phản ứng kỹ thuật hoặc bỏ qua việc vi phạm trách nhiệm đạo đức.

Nhìn thấy rất nhiều người dùng đại diện trả lời ở đây trong chủ đề này và không đề cập đến ý nghĩa đạo đức của câu hỏi làm tôi buồn.

Tôi sẽ khuyến khích mọi người đọc Quy tắc đạo đức của quản trị viên hệ thống SAGE .

BTW, kiểm toán viên bảo mật của bạn là một thằng ngốc, nhưng điều đó không có nghĩa là bạn cần cảm thấy áp lực để trở nên phi đạo đức trong công việc.

Chỉnh sửa: Cập nhật của bạn là vô giá. Giữ đầu của bạn xuống, bột của bạn khô, và không lấy (hoặc cho) bất kỳ biệt thự bằng gỗ.

Bạn không thể cho anh ta những gì bạn muốn, và cố gắng "giả", nó có khả năng quay lại cắn vào mông bạn (có thể theo những cách hợp pháp). Bạn cần phải kháng cáo chuỗi lệnh (có thể kẻ kiểm toán viên này đã lừa đảo, mặc dù kiểm toán bảo mật nổi tiếng là ngu ngốc - hãy hỏi tôi về kiểm toán viên muốn truy cập AS / 400 qua SMB), hoặc nhận được địa ngục ra từ bên dưới những yêu cầu này.

Chúng thậm chí không bảo mật tốt - một danh sách tất cả các mật khẩu văn bản gốc là một điều cực kỳ nguy hiểm từng được tạo ra, bất kể các phương pháp được sử dụng để bảo vệ chúng và tôi sẽ cá rằng bloke này sẽ muốn chúng được gửi qua email bằng văn bản đơn giản . (Tôi chắc chắn bạn đã biết điều này rồi, tôi chỉ cần trút giận một chút).

Đối với shits và cười khúc khích, hãy hỏi anh ta trực tiếp cách thực hiện các yêu cầu của anh ta - thừa nhận bạn không biết làm thế nào và muốn tận dụng kinh nghiệm của anh ta. Khi bạn ra ngoài và đi, câu trả lời cho "Tôi có hơn 10 năm kinh nghiệm trong kiểm toán bảo mật" sẽ là "không, bạn có 5 phút kinh nghiệm được lặp lại hàng trăm lần".

Không có kiểm toán viên nào làm bạn thất vọng nếu họ tìm thấy một vấn đề lịch sử mà bạn đã khắc phục. Trong thực tế, đó là bằng chứng của hành vi tốt. Với ý nghĩ đó, tôi đề nghị hai điều:

a) Không nói dối hoặc làm cho lên. b) Đọc chính sách của bạn.

Tuyên bố quan trọng đối với tôi là điều này:

Tất cả khách hàng [nhà cung cấp xử lý thẻ tín dụng chung] được yêu cầu tuân thủ các chính sách bảo mật mới của chúng tôi

Tôi cá rằng có một tuyên bố trong các chính sách đó nói rằng mật khẩu không thể được ghi lại và không thể được chuyển cho bất kỳ ai khác ngoài người dùng. Nếu có, sau đó áp dụng các chính sách đó cho các yêu cầu của mình. Tôi đề nghị xử lý nó như thế này:

• Danh sách tên người dùng hiện tại và mật khẩu văn bản đơn giản cho tất cả tài khoản người dùng trên tất cả các máy chủ

Chỉ cho anh ta một danh sách tên người dùng, nhưng không cho phép họ bị lấy đi. Giải thích rằng việc cung cấp mật khẩu văn bản đơn giản là một) không thể vì đó là một chiều và b) chống lại chính sách mà anh ta đang kiểm tra bạn, do đó bạn sẽ không tuân theo.

• Một danh sách tất cả các thay đổi mật khẩu trong sáu tháng qua, một lần nữa ở dạng văn bản đơn giản

Giải thích rằng điều này không có sẵn trong lịch sử. Đưa cho anh ta một danh sách các lần thay đổi mật khẩu gần đây để cho thấy rằng điều này hiện đang được thực hiện. Giải thích, như trên, mật khẩu sẽ không được cung cấp.

• Danh sách "mọi tệp được thêm vào máy chủ từ các thiết bị từ xa" trong sáu tháng qua

Giải thích những gì đang và không được đăng nhập. Cung cấp những gì bạn có thể. Không cung cấp bất cứ điều gì bí mật, và giải thích bằng chính sách tại sao không. Hỏi xem đăng nhập của bạn cần phải được cải thiện.

• Khóa công khai và khóa riêng của bất kỳ khóa SSH nào

Nhìn vào chính sách quản lý quan trọng của bạn. Cần nêu rõ rằng các khóa riêng không được phép ra khỏi thùng chứa của chúng và có các điều kiện truy cập nghiêm ngặt. Áp dụng chính sách đó và không cho phép truy cập. Khóa công khai là hạnh phúc công khai và có thể được chia sẻ.

• Một email được gửi cho anh ta mỗi khi người dùng thay đổi mật khẩu của họ, chứa mật khẩu văn bản đơn giản

Chỉ cần nói không. Nếu bạn có một máy chủ đăng nhập an toàn cục bộ, cho phép anh ta thấy rằng điều này đang được đăng nhập tại chỗ.

Về cơ bản, và tôi rất tiếc phải nói điều này, nhưng bạn phải chơi bóng cứng với anh chàng này. Thực hiện theo chính sách của bạn chính xác, không đi chệch hướng. Đừng nói dối. Và nếu anh ta làm bạn thất vọng vì bất cứ điều gì không có trong chính sách, hãy khiếu nại với người cao niên của anh ta tại công ty đã gửi anh ta. Thu thập một dấu vết giấy của tất cả điều này để chứng minh rằng bạn đã hợp lý. Nếu bạn phá vỡ chính sách của bạn, bạn đang thương xót anh ấy. Nếu bạn theo họ đến bức thư, cuối cùng anh ta sẽ bị sa thải.

Vâng, kiểm toán viên là một thằng ngốc. Tuy nhiên, như bạn đã biết, đôi khi những kẻ ngốc được đặt vào vị trí quyền lực. Đây là một trong những trường hợp đó.

Thông tin mà anh ta yêu cầu không ảnh hưởng đến tính bảo mật hiện tại của hệ thống. Giải thích cho kiểm toán viên rằng bạn đang sử dụng LDAP để xác thực và mật khẩu được lưu trữ bằng hàm băm một chiều. Không thực hiện một tập lệnh vũ phu chống lại băm mật khẩu (có thể mất vài tuần (hoặc nhiều năm), bạn sẽ không thể cung cấp mật khẩu.

Tương tự như vậy, các tệp từ xa - tôi muốn nghe, nói về cách anh ấy nghĩ bạn phải có khả năng phân biệt giữa các tệp được tạo trực tiếp trên máy chủ và một tệp được SCPed gửi đến máy chủ.

Như @womble đã nói, đừng giả tạo bất cứ điều gì. Điều đó sẽ làm không tốt. Hoặc bỏ cuộc kiểm toán này và phạt một nhà môi giới khác, hoặc tìm cách thuyết phục "chuyên nghiệp" này rằng phô mai của anh ta đã tuột khỏi bánh quy.

Yêu cầu "kiểm toán viên an ninh" của bạn chỉ ra bất kỳ văn bản nào từ bất kỳ tài liệu nào có yêu cầu của anh ấy và xem khi anh ấy đấu tranh để đưa ra một lý do và cuối cùng xin lỗi để không bao giờ được nghe lại.

WTF! Xin lỗi nhưng đó là phản ứng duy nhất của tôi về điều này. Không có yêu cầu kiểm toán nào tôi từng nghe về việc yêu cầu mật khẩu văn bản gốc, chứ đừng nói đến việc cung cấp cho họ mật khẩu khi chúng thay đổi.

1, yêu cầu anh ấy chỉ cho bạn yêu cầu mà bạn cung cấp.

Thứ 2, nếu đây là cho PCI (mà tất cả chúng ta đều cho rằng đó là câu hỏi về hệ thống thanh toán), hãy truy cập vào đây: https : //www.pcisecuritystiterias.org/approved_compiances_providers/qsa_compiances.php và có một kiểm toán viên mới.

Thứ 3, hãy làm theo những gì họ nói ở trên, liên hệ với quản lý của bạn và để họ liên hệ với công ty QSA mà anh ta đang làm việc. Sau đó, ngay lập tức có được một kiểm toán viên khác.

Kiểm toán viên hệ thống kiểm toán trạng thái, tiêu chuẩn, quy trình, vv Họ không cần phải có bất kỳ thông tin nào cung cấp cho họ quyền truy cập vào hệ thống.

Nếu bạn muốn bất kỳ kiểm toán viên được đề nghị hoặc người thay thế nào làm việc chặt chẽ với kiểm toán viên liên hệ với tôi và tôi rất vui lòng cung cấp tài liệu tham khảo.

Chúc may mắn! Hãy tin vào ruột của bạn, nếu có điều gì đó có vẻ sai.

Không có lý do chính đáng để anh ta biết mật khẩu và có quyền truy cập vào các khóa riêng. Những gì anh ta yêu cầu sẽ cho anh ta khả năng mạo danh bất kỳ khách hàng nào của bạn tại bất kỳ thời điểm nào và hút nhiều tiền như anh ta muốn, mà không có cách nào phát hiện ra đó là một giao dịch lừa đảo có thể. Đây sẽ chính xác là loại mối đe dọa bảo mật mà anh ta phải kiểm tra bạn.

Thông báo cho ban quản lý rằng Kiểm toán viên đã yêu cầu bạn vi phạm các chính sách bảo mật của bạn và yêu cầu đó là bất hợp pháp. Đề nghị rằng họ có thể muốn từ bỏ công ty kiểm toán hiện tại và tìm một công ty hợp pháp. Gọi cảnh sát và chuyển kiểm toán viên để yêu cầu thông tin bất hợp pháp (ở Anh). Sau đó gọi cho PCI và bật Kiểm toán viên cho yêu cầu của họ.

Yêu cầu này giống như yêu cầu bạn giết người một cách ngẫu nhiên và giao nộp xác. Bạn có làm điều đó không? hoặc bạn sẽ gọi cảnh sát và chuyển chúng vào?

Trả lời bằng một vụ kiện . Nếu một kiểm toán viên đang yêu cầu mật khẩu văn bản đơn giản (bây giờ, không khó để bẻ khóa hoặc bẻ khóa băm mật khẩu yếu), họ có thể đã nói dối bạn về thông tin đăng nhập của họ.

Chỉ là một mẹo liên quan đến cách bạn từ phản hồi của bạn:

Thật không may, không có cách nào để chúng tôi cung cấp cho bạn một số thông tin được yêu cầu, chủ yếu là mật khẩu văn bản đơn giản, lịch sử mật khẩu, khóa SSH và nhật ký tệp từ xa. Không chỉ những thứ này về mặt kỹ thuật là không thể ...

Tôi sẽ viết lại điều này để tránh tham gia vào một cuộc thảo luận về tính khả thi kỹ thuật. Đọc e-mail ban đầu khủng khiếp được gửi bởi kiểm toán viên, có vẻ như đây là người có thể chọn các chi tiết không liên quan đến vấn đề chính và anh ta có thể lập luận rằng bạn có thể lưu mật khẩu, đăng nhập, v.v. :

... Do chính sách bảo mật nghiêm ngặt của chúng tôi, chúng tôi chưa bao giờ đăng nhập mật khẩu bằng văn bản thuần túy. Do đó, về mặt kỹ thuật sẽ không thể cung cấp dữ liệu này.

Hoặc là

... Không chỉ chúng tôi sẽ giảm đáng kể mức độ bảo mật nội bộ của mình bằng cách tuân thủ yêu cầu của bạn, ...

Chúc may mắn, và giữ cho chúng tôi đăng làm thế nào điều này kết thúc!

Có nguy cơ tiếp tục sự vội vã của người dùng đại diện cao nhảy vào câu hỏi này, đây là suy nghĩ của tôi.

Tôi có thể mơ hồ thấy tại sao anh ta muốn mật khẩu văn bản gốc và đó là để đánh giá chất lượng của mật khẩu đang sử dụng. Đó là một cách tào lao để giải quyết vấn đề đó, hầu hết các kiểm toán viên mà tôi biết sẽ chấp nhận băm mật mã và chạy một cracker để xem loại trái cây treo thấp nào họ có thể rút ra. Tất cả họ sẽ xem xét chính sách phức tạp về mật khẩu và xem xét các biện pháp bảo vệ nào được áp dụng để thực thi điều đó.

Nhưng bạn phải cung cấp một số mật khẩu. Tôi đề nghị (mặc dù tôi nghĩ rằng bạn có thể đã làm điều này) hỏi anh ta mục tiêu của việc cung cấp mật khẩu văn bản gốc là gì. Anh ấy nói rằng đó là để xác nhận sự tuân thủ của bạn so với chính sách bảo mật, vì vậy hãy nhờ anh ấy đưa cho bạn chính sách đó. Hỏi anh ta nếu anh ta chấp nhận rằng chế độ phức tạp mật khẩu của bạn đủ mạnh để ngăn người dùng đặt mật khẩu của họ P@55w0rdvà có thể được áp dụng trong 6 tháng.

Nếu anh ta đẩy nó, bạn có thể phải thừa nhận rằng bạn không thể cung cấp mật khẩu văn bản gốc vì bạn không được thiết lập để ghi lại chúng (điều mà với nó là một lỗi bảo mật lớn), nhưng có thể nỗ lực trong tương lai nếu anh ta yêu cầu xác minh trực tiếp rằng chính sách mật khẩu của bạn đang hoạt động. Và nếu anh ta muốn chứng minh điều đó, bạn sẽ vui vẻ cung cấp cơ sở dữ liệu mật khẩu được mã hóa cho anh ta (hoặc bạn! Hiển thị sẵn sàng! Nó giúp!) Để vượt qua bẻ khóa.

"Các tệp từ xa" có thể được rút ra khỏi nhật ký SSH cho các phiên SFTP, đó là điều tôi nghi ngờ anh ấy đang nói đến. Nếu bạn không có syslogging 6 tháng, điều này sẽ khó sản xuất. Việc sử dụng wget để kéo tệp từ máy chủ từ xa trong khi đăng nhập qua SSH có được coi là 'truyền tệp từ xa' không? Là PUT HTTP? Tập tin được tạo từ văn bản clipboard trong cửa sổ thiết bị đầu cuối của người dùng từ xa? Nếu bất cứ điều gì, bạn có thể làm phiền anh ấy với những trường hợp cạnh này để cảm nhận rõ hơn về mối quan tâm của anh ấy trong lĩnh vực này và có lẽ thấm nhuần cảm giác "Tôi biết nhiều về điều này hơn bạn", cũng như những công nghệ cụ thể mà anh ấy nghĩ về. Sau đó trích xuất những gì bạn có thể ra khỏi nhật ký và nhật ký lưu trữ trên các bản sao lưu.

Tôi không nhận được gì trên các khóa SSH. Điều duy nhất tôi có thể nghĩ là anh ấy đang kiểm tra các khóa không mật khẩu vì một số lý do và có thể là sức mạnh của tiền điện tử. Nếu không, tôi không có gì.

Đối với việc nhận các khóa đó, việc thu thập ít nhất các khóa công khai là đủ dễ dàng; chỉ cần troll các thư mục .ssh tìm kiếm chúng. Nhận khóa riêng sẽ liên quan đến việc tặng mũ BOFH của bạn và xử lý người dùng của bạn theo giai điệu, "Gửi cho tôi cặp khóa SSH công khai và riêng tư của bạn. Mọi thứ tôi không nhận được sẽ bị xóa khỏi máy chủ sau 13 ngày" và nếu bất cứ ai vắt kiệt (tôi sẽ) chỉ vào kiểm toán bảo mật. Scripting là bạn của bạn ở đây. Tối thiểu nó sẽ gây ra một loạt các bàn phím không có mật khẩu để lấy mật khẩu.

Nếu anh ta vẫn khăng khăng "mật khẩu văn bản đơn giản trong email" thì ít nhất phải đưa các email đó vào mã hóa GPG / PGP bằng khóa riêng của mình. Bất kỳ kiểm toán viên an ninh có giá trị muối của mình sẽ có thể xử lý một cái gì đó như thế. Theo cách đó, nếu mật khẩu bị rò rỉ, đó sẽ là vì anh ta cho phép họ chứ không phải bạn. Một thử nghiệm giấy quỳ khác cho năng lực.

Tôi phải đồng ý với cả Zypher và Womble về điều này. Kẻ ngốc nguy hiểm với hậu quả nguy hiểm.

Anh ta có thể đang kiểm tra bạn để xem bạn có phải là một rủi ro bảo mật hay không. Nếu bạn cung cấp những chi tiết này cho anh ta thì có lẽ bạn sẽ bị loại bỏ ngay lập tức. Mang nó đến ông chủ ngay lập tức của bạn và vượt qua buck. Hãy cho sếp của bạn biết rằng bạn sẽ liên quan đến các cơ quan hữu quan nếu ass này đến bất cứ nơi nào gần bạn một lần nữa.

Đó là những gì ông chủ được trả tiền cho.

Tôi có một tầm nhìn về một mảnh giấy còn lại ở phía sau xe taxi có danh sách mật khẩu, khóa SSH và tên người dùng trên đó! Hừm! Có thể xem các tiêu đề báo ngay bây giờ!

Cập nhật

Đáp lại 2 bình luận bên dưới tôi đoán cả hai bạn đều có những điểm tốt để thực hiện. Không có cách nào để thực sự tìm ra sự thật và thực tế câu hỏi được đăng lên cho thấy một chút ngây thơ trên một phần của poster cũng như sự can đảm để đối mặt với một tình huống bất lợi với hậu quả nghề nghiệp tiềm năng mà những người khác sẽ cắm đầu vào cát và chạy trốn.

Kết luận của tôi cho những gì đáng giá là đây là một cuộc tranh luận hoàn toàn thú vị mà có lẽ hầu hết độc giả tự hỏi họ sẽ làm gì trong tình huống này bất kể chính sách của kiểm toán viên hay kiểm toán viên có thẩm quyền hay không. Hầu hết mọi người sẽ phải đối mặt với tình trạng khó xử này trong một số hình dạng hoặc hình thức trong cuộc sống làm việc của họ và đây thực sự không phải là trách nhiệm phải được đặt lên vai một người. Đó là một quyết định kinh doanh chứ không phải là một quyết định cá nhân về cách giải quyết vấn đề này.

Rõ ràng có rất nhiều thông tin tốt ở đây, nhưng cho phép tôi thêm 2c của mình, như một người viết phần mềm được sử dụng bởi chủ nhân của tôi cho các doanh nghiệp lớn chủ yếu để hỗ trợ mọi người tuân thủ chính sách bảo mật quản lý tài khoản và vượt qua kiểm toán; cho những gì có giá trị.

Đầu tiên, điều này nghe có vẻ rất đáng ngờ, như bạn (và những người khác) đã lưu ý. Kiểm toán viên chỉ đang làm theo một quy trình mà anh ta không hiểu (có thể) hoặc kiểm tra bạn về tính dễ bị tổn thương để kỹ thuật xã hội (không thể sau khi trao đổi tiếp theo), hoặc một kỹ thuật xã hội lừa đảo bạn (cũng có thể), hoặc chỉ là một thằng ngốc chung (có thể nhiều khả năng). Theo lời khuyên, tôi đề nghị bạn nên nói chuyện với quản lý của mình và / hoặc tìm một công ty kiểm toán mới và / hoặc báo cáo công ty này cho cơ quan giám sát thích hợp.

Đối với ghi chú, một vài điều:

• Có thể (trong các điều kiện cụ thể) để cung cấp thông tin anh ta yêu cầu, nếu hệ thống của bạn được thiết lập để cho phép thông tin đó. Tuy nhiên, nó không phải là "thực tiễn tốt nhất" cho bảo mật, cũng không phải là hoàn toàn phổ biến.
• Nói chung, kiểm toán có liên quan đến thực tiễn xác nhận, không kiểm tra thông tin an toàn thực tế. Tôi rất nghi ngờ bất kỳ ai yêu cầu mật khẩu hoặc chứng chỉ văn bản đơn giản thực tế, hơn là các phương pháp được sử dụng để đảm bảo chúng "tốt" và được bảo mật đúng cách.

Hy vọng điều đó có ích, ngay cả khi nó chủ yếu nhắc lại những gì người khác đã khuyên. Giống như bạn, tôi sẽ không nêu tên công ty của mình, trong trường hợp của tôi vì tôi không nói cho họ (tài khoản / ý kiến ​​cá nhân và tất cả); xin lỗi nếu điều đó làm giảm uy tín, nhưng vì vậy nó được. Chúc may mắn.

Điều này có thể và nên được đăng lên IT Security - Stack Exchange .

Tôi không phải là chuyên gia về kiểm toán bảo mật, nhưng điều đầu tiên tôi học được về chính sách bảo mật là "NEVER GIVE PASSWORDS AWAY". Anh chàng này có thể đã kinh doanh trong 10 năm, nhưng như Womble đã nói"no, you have 5 minutes of experience repeated hundreds of times"

Tôi đã làm việc với nhân viên IT ngân hàng một thời gian và khi tôi thấy bạn đăng bài, tôi đã cho họ xem ... Họ đã cười rất nhiều. Họ nói với tôi rằng anh chàng trông giống như một kẻ lừa đảo. Họ đã từng đối phó với loại điều này vì sự an toàn của khách hàng ngân hàng.

Yêu cầu mật khẩu rõ ràng, khóa SSH, nhật ký mật khẩu, rõ ràng là một hành vi sai trái chuyên nghiệp nghiêm trọng. Người này nguy hiểm.

Tôi hy vọng mọi thứ đều ổn và bạn không gặp vấn đề gì với thực tế là họ có thể giữ nhật ký giao dịch trước đó của bạn với họ.

Nếu bạn có thể cung cấp bất kỳ thông tin nào (ngoại trừ các khóa công khai) được yêu cầu ở các điểm 1,2,4 và 5 bạn sẽ phải thực hiện kiểm toán.

Chính thức trả lời các điểm 1,2 và 5 nói rằng bạn không thể tuân thủ vì chính sách bảo mật của bạn yêu cầu bạn không giữ mật khẩu văn bản đơn giản và mật khẩu được mã hóa bằng thuật toán không thể đảo ngược. Đến điểm 4, một lần nữa, bạn không thể cung cấp khóa riêng vì nó sẽ vi phạm chính sách bảo mật của bạn.

Đến điểm 3. Nếu bạn có dữ liệu cung cấp nó. Nếu bạn không vì bạn không phải thu thập nó thì hãy nói như vậy và chứng minh bạn hiện đang làm việc như thế nào (làm việc theo hướng) đáp ứng yêu cầu mới.

Một kiểm toán viên bảo mật cho các máy chủ của chúng tôi đã yêu cầu như sau trong vòng hai tuần :

...

Nếu chúng tôi không kiểm toán bảo mật, chúng tôi sẽ mất quyền truy cập vào nền tảng xử lý thẻ của chúng tôi (một phần quan trọng trong hệ thống của chúng tôi) và sẽ mất hai tuần để chuyển đi nơi khác . Làm thế nào tôi bị lừa?

Có vẻ như bạn đã trả lời câu hỏi của riêng bạn. (Xem văn bản in đậm để có gợi ý.)

Chỉ có một giải pháp xuất hiện: yêu cầu mọi người ghi lại mật khẩu cuối cùng và hiện tại của họ và sau đó ngay lập tức thay đổi nó thành một mật khẩu mới. Nếu anh ta muốn kiểm tra chất lượng mật khẩu (và chất lượng chuyển đổi từ mật khẩu sang mật khẩu, ví dụ để đảm bảo không ai sử dụng rfvujn125 và sau đó rfvujn126 làm mật khẩu tiếp theo của họ), thì danh sách mật khẩu cũ là đủ.

Nếu điều đó không được coi là chấp nhận được, thì tôi nghi ngờ anh chàng đó là thành viên của Anonymous / LulzSec ... tại thời điểm đó, bạn nên hỏi anh ta cách xử lý của anh ta và bảo anh ta bỏ việc như vậy!

Như oli đã nói: người được hỏi đang cố gắng khiến bạn vi phạm luật (Bảo vệ dữ liệu / Chỉ thị bảo mật của EU) / quy định nội bộ / tiêu chuẩn PCI. Bạn không chỉ phải thông báo cho quản lý (như tôi đã nghĩ), mà bạn có thể gọi cảnh sát theo đề nghị.

Nếu người được hỏi nắm giữ một số loại chứng nhận / chứng nhận, ví dụ CISA (Kiểm toán viên hệ thống thông tin được chứng nhận) hoặc tương đương với CPA của Hoa Kỳ (chỉ định kế toán công), bạn cũng có thể thông báo cho các tổ chức kiểm định để điều tra về việc này. Người đó không chỉ cố gắng khiến bạn vi phạm pháp luật, mà còn là "kiểm toán" cực kỳ bất tài và có lẽ trái với mọi chuẩn mực kiểm toán đạo đức mà theo đó các kiểm toán viên được công nhận phải tuân theo nỗi đau mất kiểm định.

Ngoài ra, nếu người được hỏi là thành viên của một công ty lớn hơn, các tổ chức kiểm toán đã đề cập thường yêu cầu một số bộ phận QA giám sát chất lượng kiểm toán và nộp đơn kiểm toán và điều tra các khiếu nại. Vì vậy, bạn cũng có thể có một khiếu nại với công ty kiểm toán trong câu hỏi.

Tôi vẫn đang nghiên cứu và điều đầu tiên tôi học được khi thiết lập máy chủ là nếu bạn có thể đăng nhập mật khẩu văn bản gốc, bạn đã tự gây nguy hiểm cho một vi phạm lớn. Không có mật khẩu nào được biết ngoại trừ người dùng sử dụng nó.

Nếu anh chàng này là một kiểm toán viên nghiêm túc, anh ta không nên hỏi bạn những điều này. Đối với tôi, anh ấy giống như một kẻ lạc lối . Tôi sẽ kiểm tra với cơ quan quản lý vì anh chàng này nghe như một thằng ngốc hoàn toàn.

Cập nhật

Đợi đã, anh ta tin rằng bạn nên sử dụng mã hóa đối xứng chỉ để truyền mật khẩu, nhưng sau đó lưu trữ bản rõ trong cơ sở dữ liệu của bạn hoặc cung cấp một cách để giải mã chúng. Về cơ bản, sau tất cả các cuộc tấn công ẩn danh vào cơ sở dữ liệu, nơi chúng hiển thị mật khẩu người dùng văn bản đơn giản, ông VẪN tin rằng đây là một cách tốt để "bảo vệ" một môi trường.

Anh ta là một con khủng long bị mắc kẹt trong những năm 1960 ...

• Danh sách tên người dùng hiện tại và mật khẩu văn bản đơn giản cho tất cả tài khoản người dùng trên tất cả các máy chủ
  • Tên người dùng hiện tại CÓ THỂ nằm trong phạm vi "chúng tôi có thể phát hành cái này" và phải nằm trong phạm vi "chúng tôi có thể chỉ cho bạn cái này, nhưng bạn không thể mang nó ra khỏi trang web".
  • Mật khẩu văn bản đơn giản không nên tồn tại lâu hơn so với băm một chiều và chúng chắc chắn không bao giờ để lại bộ nhớ (thậm chí không đi qua dây), vì vậy sự tồn tại của chúng trong bộ nhớ vĩnh viễn là không có.
• Một danh sách tất cả các thay đổi mật khẩu trong sáu tháng qua, một lần nữa ở dạng văn bản đơn giản
  • Xem "lưu trữ vĩnh viễn là không có".
• Danh sách "mọi tệp được thêm vào máy chủ từ các thiết bị từ xa" trong sáu tháng qua
  • Điều này có thể là để đảm bảo rằng bạn ghi nhật ký chuyển tệp đến / từ (các) máy chủ xử lý thanh toán, nếu bạn có nhật ký thì sẽ ổn để chuyển qua. Nếu bạn không có nhật ký, hãy kiểm tra chính sách bảo mật có liên quan nói gì về việc ghi thông tin đó.
• Khóa công khai và khóa riêng của bất kỳ khóa SSH nào
  • Có thể một nỗ lực để kiểm tra rằng 'Các khóa SSH phải có cụm từ' trong chính sách và được tuân theo. Bạn muốn có cụm từ trên tất cả các khóa riêng.
• Một email được gửi cho anh ta mỗi khi người dùng thay đổi mật khẩu của họ, chứa mật khẩu văn bản đơn giản
  • Điều này chắc chắn là không.

Tôi sẽ trả lời bằng một số câu trả lời của tôi, được hỗ trợ bởi các tài liệu chính sách bảo mật nội bộ, tuân thủ PCI, SOX_compliance và bảo mật nội bộ khi cần.

Những kẻ này yêu cầu những người mới đến thiên đàng và tôi đồng ý rằng mọi thư từ từ đây trở đi sẽ được thông qua CTO. Hoặc là anh ta đang cố gắng biến bạn thành kẻ thất bại vì không thể đáp ứng yêu cầu đã nói, để tiết lộ thông tin bí mật, hoặc là không đủ năng lực. Hy vọng rằng CTO / người quản lý của bạn sẽ thực hiện gấp đôi yêu cầu của những người này và hành động tích cực sẽ được thực hiện, và nếu họ gung ho đằng sau hành động của anh chàng này .... tốt, quản trị viên hệ thống tốt luôn luôn được yêu cầu trên các trang rao vặt, như Có vẻ như đã đến lúc bắt đầu tìm kiếm một nơi nào đó nếu điều đó xảy ra.

Tôi sẽ nói với anh ta rằng cần có thời gian, công sức và tiền bạc để xây dựng cơ sở hạ tầng bẻ khóa cho mật khẩu, nhưng vì bạn sử dụng băm mạnh như SHA256 hoặc bất cứ điều gì, có thể không thể cung cấp mật khẩu trong vòng 2 tuần. Trên hết, tôi sẽ nói rằng tôi đã liên hệ với bộ phận pháp lý để xác nhận xem có hợp pháp để chia sẻ dữ liệu này với bất kỳ ai không. PCI DSS cũng là một ý tưởng tốt để đề cập như bạn đã làm. :)

Các đồng nghiệp của tôi bị sốc khi đọc bài đăng này.

Tôi rất muốn đưa cho anh ấy một danh sách tên người dùng / mật khẩu / khóa riêng cho tài khoản honeypot sau đó nếu anh ta kiểm tra thông tin đăng nhập cho các tài khoản này để anh ta truy cập trái phép vào hệ thống máy tính. Mặc dù, thật không may, điều này có thể khiến bạn gặp phải ít nhất một kiểu tra tấn dân sự vì đã đưa ra một đại diện lừa đảo.

Đơn giản chỉ cần từ chối tiết lộ thông tin, nói rằng bạn không thể truyền mật khẩu vì bạn không có quyền truy cập vào chúng. Là một kiểm toán viên, anh ta phải đại diện cho một số tổ chức. Các tổ chức như vậy thường xuất bản hướng dẫn cho một cuộc kiểm toán như vậy. Xem nếu một yêu cầu như vậy phù hợp với những hướng dẫn. Bạn thậm chí có thể khiếu nại với các hiệp hội như vậy. Cũng nói rõ với kiểm toán viên rằng trong trường hợp có bất kỳ sai phạm nào, sự đổ lỗi có thể quay lại với anh ta (kiểm toán viên) vì anh ta có tất cả mật khẩu.

Tôi sẽ nói rằng không có cách nào để bạn cung cấp cho anh ấy BẤT K of thông tin nào được yêu cầu.

• Tên người dùng cung cấp cho anh ta thông tin chi tiết về các tài khoản có quyền truy cập vào hệ thống của bạn, một rủi ro bảo mật
• Lịch sử mật khẩu sẽ cung cấp cái nhìn sâu sắc về các mẫu mật khẩu được sử dụng cho anh ta một con đường tấn công có thể bằng cách đoán mật khẩu tiếp theo trong chuỗi
• Các tệp được chuyển đến hệ thống có thể chứa thông tin bí mật có thể được sử dụng trong cuộc tấn công vào hệ thống của bạn, cũng như cung cấp cho họ cái nhìn sâu sắc về cấu trúc hệ thống tệp của bạn
• Khóa công khai và khóa riêng, cái quái gì sẽ là điểm quan trọng khi có chúng nếu bạn đưa chúng cho ai đó không phải là người dùng dự định?
• Một email được gửi mỗi khi người dùng thay đổi mật khẩu sẽ cung cấp cho anh ta mật khẩu cập nhật cho mọi tài khoản người dùng.

Anh chàng này đang kéo bạn đời plonker của bạn! Bạn cần liên lạc với người quản lý của anh ấy hoặc một số kiểm toán viên khác trong công ty để xác nhận những yêu cầu thái quá của anh ấy. Và di chuyển đi càng sớm càng tốt.

Vấn đề được giải quyết ngay bây giờ, nhưng vì lợi ích của độc giả tương lai ...

Xem xét rằng:

• Bạn dường như đã dành hơn một giờ cho việc này.

• Bạn đã phải tham khảo ý kiến ​​tư vấn pháp lý của công ty.

• Họ đang yêu cầu rất nhiều công việc sau khi thay đổi thỏa thuận của bạn.

• Bạn sẽ hết tiền và nhiều thời gian hơn để chuyển đổi.

Bạn nên giải thích rằng bạn sẽ cần rất nhiều tiền trước mắt và có tối thiểu bốn giờ.

Vài lần trước tôi đã nói với ai đó rằng họ đột nhiên không cần thiết lắm.

Bạn vẫn có thể lập hóa đơn cho họ cho bất kỳ tổn thất nào phát sinh trong quá trình chuyển đổi và trong thời gian thực hiện, vì họ đã thay đổi thỏa thuận của bạn. Tôi không nói rằng họ sẽ trả trong vòng hai tuần, vì họ nghĩ bạn sẽ tuân thủ trong thời gian đó - họ sẽ là một chiều, tôi không nghi ngờ gì nữa.

Nó sẽ rầm rộ họ nếu văn phòng luật sư của bạn gửi thông báo thu thập. Nó sẽ thu hút sự chú ý của chủ sở hữu công ty kiểm toán viên.

Tôi sẽ khuyên bạn không nên giao dịch với họ nữa, chỉ cần thảo luận thêm về vấn đề này sẽ đòi hỏi phải đặt cọc cho công việc cần thiết. Sau đó, bạn có thể được trả tiền để nói với họ.

Thật kỳ lạ khi bạn có một thỏa thuận có hiệu lực và sau đó ai đó ở đầu kia sẽ ra khỏi đường ray - nếu đó không phải là một bài kiểm tra về an ninh hay trí thông minh thì đó chắc chắn là một bài kiểm tra sự kiên nhẫn của bạn.