Những chiến lược nào có thể được sử dụng để bảo mật dữ liệu nhạy cảm trong các tệp nhật ký?


7

Làm việc trong môi trường quy định cao dữ liệu được phân loại theo các cách khác nhau tùy thuộc vào độ nhạy. Trong một số trường hợp, điều này được thực thi một cách hợp pháp và phải được đối xử khác nhau.

Ví dụ về chính sách phân loại dữ liệu là:

  • Dữ liệu bị hạn chế cao , chẳng hạn như Mật khẩu, Khóa riêng, Mã thông báo SAML và Số thẻ tín dụng.
  • Dữ liệu bị hạn chế , chẳng hạn như Tên người dùng và ID khách hàng.
  • Dữ liệu không hạn chế , khá nhiều thứ khác.

Phân loại này đi kèm với các nghĩa vụ nhất định:

  • Bất kỳ dữ liệu nào bị hạn chế cao không bao giờ được cung cấp trong tệp nhật ký trong mọi trường hợp.

  • Dữ liệu bị hạn chế có thể được cung cấp trong các tệp nhật ký trong các điều kiện cụ thể. Ví dụ: nếu sự cố xảy ra với một dịch vụ thì kỹ sư trực điện thoại có thể thực hiện quy trình Break-Glass để truy cập dữ liệu này để chẩn đoán sự cố. Đến lượt, thủ tục Break-Glass sẽ kích hoạt đánh giá, kiểm toán và có thể thu hồi đặc quyền tạm thời từ kỹ sư đó.

Những chiến lược nào có thể được sử dụng để đạt được điều này, đặc biệt là có rất nhiều công cụ ghi nhật ký, giám sát và thiết bị có sẵn trên thị trường không cung cấp câu trả lời trực tiếp cho vấn đề này?

Ví dụ, cả Splunk và AppDoperics đều có khả năng áp đặt các điều khiển truy cập khác nhau theo các điều kiện từ xa bị lộ; điều này có nghĩa là bạn có thể tạo một bộ lọc che đi <customerId>NNNNNNNNNNNN</customerId>. Tuy nhiên, cả hai công cụ này đều không cung cấp cho bạn khả năng tự động xác định số thẻ tín dụng và tự động che giấu chúng.

Lưu ý : Tôi tin rằng điều này có liên quan đến DevOps vì trong mô hình hỗ trợ theo tầng truyền thống, một nhóm người tương đối nhỏ có thể truy cập dữ liệu và lọc thủ công, bằng cách dành trách nhiệm cho các nền tảng vận hành cho các nhóm phát triển, dữ liệu này có khả năng bị phơi bày từ xa đối tượng rộng hơn.


Là câu hỏi về hệ thống nguồn đóng / Saas, hoặc chung chung hơn để bao gồm ngăn xếp ELK?
Tensibai 18/03/17

Tôi nghi ngờ bất cứ điều gì áp dụng cho các sản phẩm ghi nhật ký và từ xa SaaS đều có thể được áp dụng cho các công cụ Nguồn mở. Có thể có các tính năng hỗ trợ điều này, như khả năng Splunks định tuyến đến các nhóm khác nhau dựa trên các quy tắc hoặc mặt nạ dữ liệu nhưng chúng cũng có sẵn trên Ngăn xếp nguồn mở ở một mức độ khác.
Richard Slater

1
@ Pierre.Vriens ELK = ElasticSearch, LogStash và Kibana: thun.co/webinars/int sinhtion
Richard Slater

@RichardSlater merci cho việc giảng dạy!
Pierre.Vriens

1
@ Pierre.Vriens Tôi tin rằng đó là DevOps bởi vì trước đó, một nhóm người tương đối nhỏ có thể truy cập dữ liệu và lọc dữ liệu theo cách thủ công, bằng cách dành trách nhiệm cho các nền tảng vận hành cho các nhóm phát triển, dữ liệu này có khả năng tiếp xúc với đối tượng rộng hơn.
Richard Slater

Câu trả lời:


4

Tôi nghĩ rằng giải pháp đưa ra một loạt các phương pháp tiếp cận đảm bảo bảo vệ dữ liệu:

  • Phân loại dữ liệu : Chiến lược kỹ thuật hiệu quả nhất là phân loại dữ liệu tại điểm tạo một cách chặt chẽ. Tại cốt lõi của nó, các nhà phát triển có trách nhiệm đảm bảo rằng tất cả các thông tin đã đăng nhập được chỉ định một danh mục. Ví dụ, phân loại có thể đạt được thông qua Siêu dữ liệu Splunk , lần lượt, có thể được sử dụng để hướng các mục nhật ký đến các nhóm khác nhau dựa trên phân loại dữ liệu của chúng.

  • Phân vùng sự kiện : Thường có mong muốn ghi thông tin nhạy cảm cùng với thông tin không nhạy cảm. Ví dụ: nếu người dùng mới đăng ký, bạn có thể đăng nhập:

    • ID khách hàng (bị hạn chế)
    • Loại khách hàng (Bị hạn chế)
    • Nguồn Aquisition (Không giới hạn)
    • ID tương quan (Không giới hạn)

    Có thể chia một "Sự kiện" này thành hai phần, một phần chứa thông tin Hạn chế và một phần chứa thông tin Không hạn chế . Điều này phù hợp với điểm đầu tiên bằng cách cho phép các quy tắc lọc hướng trực tiếp đến các nhóm khác nhau.

  • Mặt nạ dữ liệu : Trong các trường hợp cụ thể, có thể không thể phân loại dữ liệu tại nguồn, theo kinh nghiệm của tôi, các giải pháp ghi nhật ký cho phép Quy tắc che mặt để loại bỏ dữ liệu nhạy cảm. Trong ví dụ được liên kết, một sedlệnh được sử dụng để áp dụng biểu thức chính quy cho tất cả dữ liệu từ một nguồn cụ thể. Khi dữ liệu bị hạn chế đã bị che giấu thì sự kiện có thể được coi là Không bị hạn chế. Phải cẩn thận với quy tắc để đảm bảo rằng thông tin quan trọng đối với một sự kiện, chẳng hạn như ID tương quan không khớp với Biểu thức chính quy được sử dụng để khớp với dữ liệu nhạy cảm.

  • Lọc sự kiện : Như là phương sách cuối cùng, có thể cần phải lọc tất cả các sự kiện thuộc một loại hoặc nguồn cụ thể vào một nhóm riêng nếu chúng chứa dữ liệu nhạy cảm không thể phân loại hoặc che giấu. Trong trường hợp này, thông tin trong một thùng bị hạn chế chỉ có thể được truy cập thông qua cơ chế Break-Glass để bỏ qua các kiểm soát truy cập theo quy định của một sự cố.

Với mỗi giải pháp này, kiểm tra là chìa khóa để đảm bảo rằng không có gì trượt qua vết nứt. Ghi nhật ký và Quản lý sự kiện phải được coi là một Yêu cầu phi chức năng hạng nhất với cùng mức độ nghiêm ngặt về phát triển được áp dụng cho một giải pháp - bao gồm đánh giá ngang hàng và kiểm tra để đảm bảo dữ liệu được phân loại và phân vùng chính xác trong công cụ lựa chọn.


0

Nó phụ thuộc vào những gì bạn có nghĩa là "tập tin nhật ký" tôi nghĩ. Nếu bạn có nghĩa là dữ liệu từ xa bạn sử dụng để xác minh hệ thống của bạn đang hoạt động chính xác, tôi sẽ nói "Đừng ghi nhật ký các trường nhạy cảm." Bạn không cần loại thông tin đó để cảnh báo bạn về tỷ lệ giao dịch cao hay thấp, thời gian phản hồi cho các dịch vụ phụ thuộc của bạn, v.v.

Nếu bạn có nghĩa là dữ liệu cho mục đích thanh toán hoặc kiểm toán, tôi sẽ đề nghị bạn thiết lập một đường ống chỉ ghi trong đó dữ liệu được ghi nhưng người viết không thể đọc được. Sau đó, đường ống thanh toán và kiểm toán của bạn bắt đầu và bạn có các kiểm soát ở đó để kiểm toán những người đã xem hồ sơ cá nhân.

Cuối cùng, bảo mật được đưa vào các quy trình được ghi lại bằng các tệp nhật ký bảo mật của riêng họ, v.v. Tại một số điểm, bạn phải tin tưởng ai đó hoặc một số quy trình vì tất cả dữ liệu được ghi để sau đó có thể đọc được.


bỏ phiếu không có bình luận. đẹp. Quỷ ở khắp mọi nơi.
Không hoàn lại tiền Không trả lại
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.