it-swarm-vi.com

Quản lý khóa mã hóa ứng dụng web

Tóm lại, hãy xem xét một ứng dụng web lưu trữ một số thông tin trong cơ sở dữ liệu dưới dạng dữ liệu được mã hóa. Trong khi tôi cố tình giữ điều này một số chung chung, đây là một số giả định:

  • Dữ liệu được mã hóa chỉ được lưu trữ trong cơ sở dữ liệu (không phải ở nơi khác). Một số trường trong một bản ghi đã cho được mã hóa, một số thì không.
  • Ứng dụng web phải ghi dữ liệu được mã hóa vào cơ sở dữ liệu.
  • Ứng dụng web phải có khả năng đọc và hiển thị dữ liệu được mã hóa. Dữ liệu chỉ được hiển thị trong phần xác thực và được quản lý của ứng dụng.
  • Dữ liệu là thông tin nhạy cảm cần được bảo vệ trong trường hợp dữ liệu bị lộ/truy cập (không có phím *).

Câu hỏi :

  • Nơi/làm thế nào để bạn lưu trữ (các) khóa được sử dụng để mã hóa? Thứ nhất, trong một hệ thống mà các máy chủ web và cơ sở dữ liệu giống nhau, làm thế nào để bạn quản lý khóa? Thứ hai, trong các hệ thống mà máy chủ web và máy chủ DB tách biệt, làm thế nào để bạn quản lý khóa?
  • Là các khóa chỉ là tập tin hạn chế quyền? Được lưu trữ trong một số công cụ/phần mềm riêng biệt? Tôi đã thấy đề cập rằng đôi khi các khóa mã hóa cũng được mã hóa, nhưng không rõ nơi nào có thể giúp đỡ.

Tôi biết đây là một câu hỏi bảo mật khá cơ bản và vì vậy nếu có những tài nguyên mà có lẽ tôi đang thiếu thì cũng sẽ rất, rất hữu ích. Tôi đã dành rất nhiều thời gian (trong nhiều năm) để cố gắng nắm bắt thông tin này dựa trên thông tin về bảo mật ứng dụng web (OWASP, PCI DSS, v.v.), nhưng nhiều lần thông tin này rất chung chung (ví dụ: "bảo vệ dữ liệu "," mã hóa dữ liệu ") hoặc rất cụ thể (" để mã hóa thứ gì đó bằng AES làm điều này ... ").

* Tôi hiểu rằng đây không phải là một giải pháp bảo mật hoàn chỉnh theo đúng nghĩa của nó. Tôi hiểu rằng có một số vectơ để có được thông tin này và giải mã nó. Tôi thừa nhận rằng đây có thể là một câu hỏi kém trong ánh sáng đó :)

Đã chỉnh sửa để thêm thông tin về các giả định cho câu hỏi này

47
Rob

Nơi/làm thế nào để bạn lưu trữ (các) khóa được sử dụng để mã hóa?

Cách tiếp cận tiêu chuẩn nếu bạn đang sử dụng mã hóa tích hợp trên một cái gì đó như cơ sở dữ liệu SQL hoặc Oracle, cơ sở dữ liệu sẽ tạo khóa mã hóa và mã hóa mã này bằng khóa bảo vệ khóa khác hoặc khóa Master. Đây có thể là cụm mật khẩu hoặc khóa dài hơn được lưu trữ trong ví dụ: tập tin .pem.

Điều này thường được lưu trữ trong một thư mục bị hạn chế mà chỉ root/Administrator và tài khoản dịch vụ cơ sở dữ liệu có thể truy cập. Khi khởi động cơ sở dữ liệu, khóa được đọc và tải vào bộ nhớ. Điều này sau đó được sử dụng để giải mã các khóa mã hóa.

Thứ nhất, trong một hệ thống có máy chủ cơ sở dữ liệu và web giống nhau, bạn quản lý khóa như thế nào?

Khóa được lưu trữ trong một thư mục trên máy chủ. Để gia hạn hoặc thu hồi thường thông qua chương trình cơ sở dữ liệu.

Thứ hai, trong các hệ thống có máy chủ web và máy chủ DB riêng biệt, bạn quản lý khóa như thế nào?

Khóa được lưu trữ cục bộ trên máy chủ cơ sở dữ liệu. Tùy chọn an toàn hơn là sử dụng Mô-đun bảo mật phần cứng (HSM) trong cả hai trường hợp. Đây là một thiết bị phần cứng được gắn vào máy chủ và được sử dụng để lưu trữ khóa chứ không phải là một thư mục bị hạn chế trên máy chủ.

Các khóa chỉ là các tệp bị hạn chế quyền? Được lưu trữ trong một số công cụ/phần mềm riêng biệt? Tôi đã thấy đề cập rằng đôi khi các khóa mã hóa cũng được mã hóa, nhưng không rõ nơi nào có thể giúp đỡ.

Hạn chế thư mục được chấp nhận miễn là bạn quản lý quyền truy cập của quản trị viên và giám sát những thứ như đăng nhập trái phép, đăng nhập như tài khoản dịch vụ, tài khoản hoặc nhóm mới được thêm quyền truy cập vào thư mục. Như đã đề cập ở trên, HSM là tùy chọn an toàn hơn nếu dữ liệu bạn đang bảo vệ và các mối đe dọa mà bạn đang phải đối mặt cần nó.

Nói chung, cơ sở dữ liệu sẽ tạo các khóa đối tượng hoặc bảng và sau đó mã hóa mã này bằng khóa chính. Có lợi ích tối thiểu trong việc mã hóa thêm khóa chủ.

11
Rakkhi

Mặc dù một số thông tin tốt đã được cung cấp trong câu trả lời trước đó, có một lỗ hổng thiết kế quan trọng, không thực sự được chú ý - nhưng xuất phát từ một số giả định ngầm trong câu hỏi.

Sự khác biệt không nên nằm giữa:

  • Ứng dụng web và DB trên cùng một máy chủ
  • Ứng dụng web và DB trên các máy chủ khác nhau
  • ứng dụng so với mã hóa db

Thiết kế nên bắt đầu từ:

  • Ai cần truy cập vào (các) khóa mã hóa/giải mã?

Hoặc, thực sự thậm chí còn đúng hơn:

  • Ai chịu trách nhiệm bảo vệ tính bảo mật của dữ liệu?

Mà, đến lượt nó, đến từ:

  • Những mối đe dọa nào bạn đang cố gắng bảo vệ chống lại?
    Hoặc là
  • Bạn đang cố gắng ngăn ai đọc dữ liệu của bạn?

Chỉ dựa trên những câu hỏi này, bạn có thể thiết kế một hệ thống mật mã được thiết kế đúng. (Và ngăn bụi tiền điện tử mà @ D.W. Đã đề cập).

Vì vậy, một số tình huống ví dụ:

  • Người dùng phải chịu trách nhiệm mã hóa, ngăn chặn ngay cả quản trị viên ứng dụng nhìn thấy dữ liệu
  • Ứng dụng khách phải có trách nhiệm, không cần phải liên quan đến người dùng - nhưng điều này vẫn cần được thực hiện ở phía máy khách (ví dụ: chương trình sao lưu).
  • Máy chủ ứng dụng mã hóa dữ liệu được chọn một cách cụ thể và cụ thể, như một phần của logic nghiệp vụ (ngay cả dba cũng không thể nhìn thấy dữ liệu)
  • Máy chủ cơ sở dữ liệu sẽ tự động và minh bạch mã hóa dữ liệu được lưu trữ. (Điều này chỉ bảo vệ chống trộm tệp db/đĩa vật lý, với cảnh báo ...).

Để đơn giản, hãy giả sử rằng mã hóa phải được thực hiện ở phía máy chủ, trách nhiệm thuộc về máy chủ và người dùng cuối (và quản trị viên) không ảnh hưởng đến mã hóa.

Câu hỏi chính là mã hóa được thực hiện bởi máy chủ ứng dụng hay máy chủ cơ sở dữ liệu? (Trên thực tế không đơn giản như vậy, có những lựa chọn khác ...)
[.__.] Điều này, như hầu hết các vấn đề bảo mật, trở lại với sự đánh đổi:

  • Bạn sẽ quản lý các khóa riêng của mình, hay bạn thích cơ sở hạ tầng này một cách tự động? (câu hỏi ban đầu ... thêm thông tin bên dưới ...)
  • Bạn có lo lắng về độc hại (hoặc bất tài thiếu kinh nghiệm) lập trình viên?
  • Bạn có lo lắng về quản trị viên độc hại?
  • Bạn có lo lắng về việc sử dụng ứng dụng trái phép?
  • Bạn có lo lắng về việc truy cập SQL trái phép?
  • Bạn có lo lắng về việc truy cập tập tin trực tiếp trái phép?
  • Bạn có lo lắng về trộm cắp đĩa/máy chủ vật lý?

Và như thế. (Lưu ý rằng một số câu hỏi trên không liên quan và không thể giải quyết bằng mã hóa máy chủ).


Bây giờ, giả sử bạn đã đưa ra quyết định của mình, dựa trên những điều trên, giữa mã hóa máy chủ ứng dụng và mã hóa cơ sở dữ liệu.
[.__.] Lưu ý rằng liệu máy chủ web và db có nằm trên cùng một máy chủ hay không, hầu như không có tác dụng gì ở đây - nếu ứng dụng được mã hóa, thì nó chỉ gửi dữ liệu "đặc biệt" tới db, nếu không thì nó vẫn còn. Tuy nhiên, điều này không ảnh hưởng đến cuộc thảo luận về các mối đe dọa ở trên - một số vấn đề bị lỗi thời bởi thiết kế, một số vấn đề được nâng cao ...

  • Mã hóa máy chủ ứng dụng/web [.__.]
    • Khóa mã hóa (EK) bạn sử dụng để mã hóa dữ liệu, phải được mã hóa bằng khóa mã hóa (KEK).
    • EK được mã hóa phải được lưu trữ ở nơi được bảo vệ - đây có thể là tệp, khóa đăng ký, bất cứ điều gì - điều quan trọng là hạn chế quyền truy cập vào nó, chỉ cho người dùng của máy chủ ứng dụng (và có lẽ là quản trị viên - xem bên dưới).
    • KEK cũng cần được bảo vệ - điều này phức tạp hơn một chút.
      [.__.] Nếu bạn đang ở trên Windows, bạn có thể dễ dàng truy cập DPAPI - điều này cung cấp quản lý khóa cấp hệ điều hành, do đó bạn có thể có HĐH mã hóa KEK của bạn và quản lý các khóa cho bạn một cách minh bạch. (Đằng sau hậu trường, DPAPI cuối cùng cũng dựa vào việc biết mật khẩu của người dùng (trong USER_MODE), vì vậy đó là điểm yếu cuối cùng của một bí mật được biết đến thực sự - nhưng không ai khác nên biết Mật khẩu của máy chủ ở nơi đầu tiên, phải không?)
      [.__.] Một tùy chọn khác là thiết bị bên ngoài/HSM, được thảo luận thêm bên dưới.
    • KEK cũng cần kiểm soát truy cập, tất nhiên - ACL hạn chế và tất cả những thứ đó.
    • Có một số lý do bạn muốn tách EK khỏi KEK: bạn không muốn mã hóa lượng dữ liệu khổng lồ bằng một khóa duy nhất; nếu bạn cần thay thế khóa, việc này trở nên dễ dàng hơn rất nhiều (chỉ cần mã hóa lại EK bằng KEK mới); bạn có thể sử dụng mã hóa/lưu trữ mạnh hơn, chậm hơn, phức tạp hơn trên KEK; nếu bạn cần tuân thủ PCI, bạn có thể triển khai kiến ​​thức phân tách trên KEK; và hơn thế nữa.
    • Cả EK và KEK không nên được lưu trữ lâu dài không được mã hóa - tùy thuộc vào nền tảng/ngôn ngữ của bạn, điều này có nghĩa là ví dụ: không lưu trữ nó trong một đối tượng String trong .NET hoặc Java. Thay vào đó, lưu trữ nó trong các mảng byte có thể thay đổi và luôn đảm bảo bạn loại bỏ nó càng sớm càng tốt.
    • Một số khung thậm chí còn tiến thêm một bước và cung cấp các đối tượng được bảo vệ cụ thể. Ví dụ. trong .NET, bạn có thể sử dụng các lớp System.Security.Cryptography.ProtectedMemory và/hoặc System.Security.Cryptography.ProtectedData để giữ các khóa được bảo vệ, ngay cả trong bộ nhớ.
  • Mã hóa cơ sở dữ liệu [.__.]
    • Nếu máy chủ cơ sở dữ liệu của bạn thực hiện mã hóa, việc này trở nên dễ dàng hơn nhiều: các bảng/trường được cấu hình để tự động mã hóa bất kỳ dữ liệu nào được lưu trữ trong đó, quản lý khóa hoàn toàn trong suốt (từ PoV của ứng dụng, không phải DBA) và Sớm.
    • Ví dụ, cả Oracle và MS SQL Server đều hỗ trợ mã hóa tích hợp tự động. Đối với MSSQL, việc quản lý khóa rất phức tạp, nhưng tương tự như những gì tôi đã mô tả ở trên. Đơn giản hóa: Có một EK, được lưu trữ trong cơ sở dữ liệu, dba có thể cấu hình để sử dụng để mã hóa/giải mã các bảng hoặc trường. Đây là trong một bảng được bảo vệ, được mã hóa bởi KEK, lần lượt được mã hóa bởi cấp độ máy chủ KEK, lần lượt được mã hóa bằng DPAPI trên tài khoản dịch vụ của MSSQL.
    • Ngoài ra, MSSQL cũng hỗ trợ sử dụng mã hóa không đồng bộ, ví dụ: lưu trữ các cặp khóa công khai/riêng tư - điều này có thể hữu ích trong các tình huống cụ thể.
  • Tùy chọn thứ ba: lưu trữ mã hóa bên ngoài hoặc HSM (mô-đun bảo mật phần cứng) . Đây có thể là một thiết bị phần cứng, máy chủ hoặc thẻ phần cứng hoặc dongle ... vv. [.__.]
    • Các thiết bị này được thiết kế để bảo vệ rất an toàn các bit dữ liệu nhỏ - ví dụ: KEK của bạn.
      [.__.] Một lần nữa, một lý do khác khiến EK tách khỏi KEK - điều này sẽ cho phép bạn mã hóa và giải mã hiệu quả khối lượng dữ liệu bằng EK, trong khi vẫn quản lý KEK một cách an toàn.
    • HSM thường được truy cập thông qua trình điều khiển hoặc API đặc biệt, có thể cũng có thể cắm chúng vào mã hóa cơ sở dữ liệu (tùy thuộc vào sản phẩm, v.v.).
29
AviD