it-swarm-vi.com

Chiến lược thực dụng phổ biến để quản lý các cặp chìa khóa là gì?

Tôi có một số lượng nhỏ các máy trạm khác nhau (cộng với các thiết bị khách như iPhone) mà tôi sử dụng để kết nối với nhiều máy chủ bằng SSH.

Ban đầu khi tôi biết về PKI, tôi đã tạo một cặp khóa duy nhất trên máy trạm của mình, tôi đã nhanh chóng bắt đầu sử dụng từ mọi nơi (nghĩa là tôi đã sao chép nó vào máy tính xách tay của mình, v.v.) và sử dụng nó để kết nối với tất cả các tài khoản máy chủ của mình.

Kể từ đó, tôi đã phát triển ý kiến ​​rằng đây giống như sử dụng một mật khẩu duy nhất ở mọi nơi và tôi có thể cần phải thu hồi quyền truy cập có chọn lọc, ví dụ: nếu một trong những máy trạm của tôi bị xâm phạm.

Về cơ bản, tôi đang cố gắng phát triển một chiến lược cá nhân để đối phó với các cặp chính:

Cách đúng đắn để suy nghĩ về các cặp khóa an toàn cho sử dụng chung, trong khi vẫn còn thực dụng cho khả năng sử dụng là gì? (tức là tôi không nghĩ các cặp khóa sử dụng một lần cho mọi điểm kết nối nhất thiết phải có ý nghĩa.)

Có phải sai khi một cặp khóa đại diện cho một danh tính cá nhân trên toàn cầu từ tất cả các điểm truy cập ("tôi-mọi nơi-id_rsa") như tôi đã làm trong quá khứ hay là suy nghĩ hiện tại của tôi rằng một kết hợp khách hàng-người dùng duy nhất phải luôn được đại diện bởi khóa riêng của nó ("me-on-my-Personal-laptop-id_rsa") phù hợp hơn?

Bạn có sử dụng lại cùng một khóa để kết nối với tất cả các máy chủ không, hoặc trong những điều kiện nào bạn xem xét việc đúc một khóa riêng?

48
Andrew Vit

Tôi thích có một khóa cho mỗi lĩnh vực xác thực. Do đó, đối với mọi máy tính để bàn hoặc máy chủ tại nơi làm việc (tất cả đều khá an toàn về mặt vật lý và dưới sự kiểm soát của một nhóm quản trị viên), tôi có một khóa riêng. Tôi sử dụng cùng khóa riêng trên PC nhà mới của tôi như PC cũ của tôi. Tôi sử dụng các phím khác nhau trên máy tính xách tay và các thiết bị di động khác. Cách tiếp cận này cho phép quản lý rủi ro chi tiết: Tôi có thể thu hồi các khóa riêng biệt và hạn chế khả năng tài khoản của tôi bị xâm nhập bằng cách không cho phép một số khóa nhất định trên một số máy nhất định (Tôi không làm như vậy, nhưng đó là một tùy chọn cho người hoang tưởng).

Miễn là bạn không làm gì phức tạp, sao chép các khóa công khai không khó. Bạn có thể giữ một danh sách lớn các khóa được ủy quyền và đồng bộ hóa nó ở mọi nơi; đăng ký một thiết bị có nghĩa là thêm một mục vào danh sách đó và thúc đẩy thay đổi. Điều này không hiệu quả hơn nhiều so với việc rút khóa riêng, nếu bạn có kho lưu trữ dữ liệu trung tâm ở nơi đầu tiên.

Lưu ý rằng mặc dù lợi thế rõ ràng nhất của việc có các khóa riêng là có thể thu hồi một khóa riêng, nhưng chúng cũng có một lợi ích sẵn có: nếu quản trị viên hệ thống trên máy A quyết định thu hồi khóa của máy C mà bạn đang bật, bạn vẫn có thể tìm thấy một số máy B vẫn chấp nhận khóa C và khóa đó được chấp nhận bởi A. Điều này có vẻ khá bí truyền, nhưng điều này đã xảy ra một lần với tôi (sau Debian nhận ra họ không gieo RNG của họ , tôi rất vui khi không phải phụ thuộc hoàn toàn vào khóa trong danh sách đen) trong khi tôi chưa phải thu hồi khóa trong trường hợp khẩn cấp.

Thậm chí còn có một lợi ích về mặt lý thuyết trong việc giữ một cặp khóa riêng cho mỗi cặp máy, trong đó nó cho phép hủy bỏ riêng biệt. Nhưng lợi ích là vô cùng nhỏ, và việc quản lý khó khăn hơn rất nhiều (bạn không còn có thể phát danh sách ủy quyền). Đơn giản hóa việc quản lý khóa là một lợi thế quan trọng của mật mã khóa công khai so với các bí mật được chia sẻ.

Bạn đã thấy điểm chính: nếu một trong các máy của bạn bị xâm nhập, khóa riêng có trong máy này phải được "thu hồi": bạn phải định cấu hình tất cả các máy chủ mà bạn kết nối để từ chối các lần xác thực tiếp theo bằng cách sử dụng khóa đó (tức là bạn xóa khóa công khai tương ứng từ .ssh/authorized_keys của các máy chủ). Có một kỹ thuật giảm thiểu, bao gồm bảo mật khóa riêng bằng mật khẩu (hoặc cụm mật khẩu). Điều này đi kèm với một mức giá, cụ thể là bạn phải nhập mật khẩu ( ssh-agent có thể khá tiện cho việc đó); mặt khác, điều này có thể tạm thời ngăn chặn kẻ tấn công lấy khóa riêng (điều này phụ thuộc vào loại thỏa hiệp, nhưng nếu đó là hành vi trộm cắp máy hoàn chỉnh - một kịch bản hợp lý với thiết bị di động - thì mật khẩu sẽ ngăn chặn truy cập ngay vào khóa riêng và cho bạn một chút thời gian để cấu hình lại các máy chủ).


Mọi người có thể lưu ý rằng "PKI" có nghĩa là "Khóa công khai Cơ sở hạ tầng" và SSH là thô sơ trong khía cạnh đó. Trong PKI toàn diện, chứng chỉ sẽ được sử dụng, với sự ủy nhiệm và tập trung thu hồi. Có chứng chỉ:

  • bạn sẽ tạo một cặp khóa CA, được lưu trữ an toàn ở đâu đó;
  • đối với mỗi máy khách, bạn sẽ có được một cặp khóa mới, khóa chung là đã ký bởi CA;
  • các máy chủ sẽ được cấu hình để tự động chấp nhận any khóa chung được ký bởi CA (họ sẽ biết khóa chung CA, nhưng không phải là khóa máy khách riêng lẻ);
  • cA sẽ duy trì và thường xuyên xuất bản thông tin thu hồi, tức là danh sách các khóa công khai không còn được chấp nhận mặc dù vậy các khóa này được ký bởi CA (thông tin hủy bỏ phải được đẩy đến máy chủ, hoặc kéo theo yêu cầu).

Điều tuyệt vời về chứng chỉ là bạn tập trung hóa các quyết định, theo nghĩa thực tế, có nghĩa là nếu bạn kết nối với 20 máy chủ từ máy khách của mình, sau đó thêm máy khách mới, bạn không phải tự đẩy khóa công khai mới vào Tất cả 20 máy chủ.

OpenSSH , kể từ phiên bản 5.4 (phát hành ngày 8 tháng 3 năm 2010), có một số hỗ trợ cho chứng chỉ; xem phần cùng tên trong trang man cho ssh-keygen . Chứng chỉ OpenSSH có định dạng đơn giản hơn nhiều so với chứng chỉ X.509 "thông thường" (như được sử dụng với SSL). Việc đơn giản hóa cũng có một mức giá: không có hỗ trợ thu hồi tập trung. Thay vào đó, nếu khóa riêng bị xâm phạm, bạn vẫn phải đưa vào danh sách đen khóa công khai tương ứng trên tất cả các máy chủ và trong danh sách đen, trong OpenSSH, danh sách trắng (tùy chọn AuthorizedPrincipalsFile in sshd_config), thông thường, dưới sự kiểm soát của root. Vì vậy, việc thu hồi không hoạt động tốt và bạn vẫn phải tự cấu hình mọi thứ trên mỗi máy chủ bất cứ khi nào bạn tạo hoặc mất một khóa, điều bất tiện chính xác là PKI phải hủy bỏ.

Bạn could vẫn tạo các khóa giới hạn thời gian, vì chứng chỉ OpenSSH có thể nhúng các khóa giới hạn thời gian. Trong trường hợp đó, bạn sẽ cung cấp cho mỗi máy khách một khóa tốt, giả sử, một tuần. Với các khóa chết sau một tuần và khóa công khai CA được các máy chủ biết đến, bạn có lòng tốt CA chính (không cần phải đẩy bất cứ thứ gì trên tất cả các máy chủ khi máy mới được thêm vào nhóm máy khách) và nếu là riêng tư khóa bị xâm phạm, thiệt hại là "có giới hạn", giả sử bạn có mật khẩu khóa, có lẽ, sẽ chống lại một tuần bẻ khóa (nhưng điều này sẽ không hoạt động nếu thỏa hiệp là tiếp quản thù địch với bộ ghi chép khóa). Các khóa bị giới hạn thời gian có thể phát triển tẻ nhạt theo thời gian và họ cho rằng tất cả các máy chủ đều có đồng hồ được đặt chính xác, điều này không phải lúc nào cũng được đưa ra (thật không may khi bị khóa khỏi máy chủ vì đồng hồ máy chủ bị tắt và đặt lại đồng hồ yêu cầu truy cập SSH vào máy chủ ...).

Một vấn đề khác với SSH là rất dễ dàng để thêm khóa công khai trên mỗi máy chủ. Điều này có nghĩa là nếu kẻ tấn công xâm phạm khóa riêng và giành quyền truy cập vào máy chủ một lần, anh ta có thể thêm khóa công khai của riêng mình vào .ssh/authorized_keys trên máy chủ đó và không có khoản thu hồi nào sẽ khắc phục điều đó. Thu hồi, về bản chất, là một quá trình không đồng bộ. Do đó, nó không thực hiện kiểm soát thiệt hại đủ nghiêm ngặt.


Do những thiếu sót của hỗ trợ SSH cho chứng chỉ, không có sơ đồ hợp lý nào tránh được việc phải thực hiện một số cấu hình trên tất cả các máy chủ trong một số tình huống. Vì vậy, về cơ bản bạn có các lựa chọn sau, khi bạn thêm một máy khách mới:

  1. Bạn sao chép khóa riêng từ một máy khách khác (đó là những gì bạn đang làm ngay bây giờ). Điều này không yêu cầu cấu hình thêm trên các máy chủ.

  2. Bạn tạo một cặp chìa khóa mới cho máy đó. Bạn phải Đẩy khóa công khai tới tất cả các máy chủ.

Trước sự thỏa hiệp của khóa, bạn phải kết nối với tất cả các máy chủ để xóa khóa chung tương ứng khỏi tất cả .ssh/authorized_keys. Điều này là không thể tránh khỏi (để tránh nó, bạn sẽ phải sử dụng chứng chỉ và SSH không tốt về chứng chỉ, xem ở trên). Sau đó, if bạn đã sử dụng lựa chọn 1, sau đó bạn phải cũng tạo một cặp khóa mới và Đẩy nó tới tất cả client = máy đang sử dụng bản sao của khóa riêng bị xâm nhập.

Do đó, lựa chọn 1 đòi hỏi công việc cấu hình ít hơn so với lựa chọn 2 trong trường hợp bình thường, nhưng mọi thứ sẽ đảo ngược nếu xảy ra thỏa hiệp chính. Vì sự thỏa hiệp thường là những sự kiện hiếm gặp, điều này sẽ ủng hộ lựa chọn 1 (đó là những gì bạn đã làm). Vì vậy, tôi khuyên bạn nên bảo vệ khóa riêng của mình bằng mật khẩu mạnh và sao chép nó vào tất cả các hệ thống máy khách của bạn.

Lưu ý: trong tất cả các mục trên, tôi giả sử rằng bạn muốn kết nối với danh sách máy chủ bằng SSH và bạn muốn truy cập bất kỳ máy chủ nào từ bất kỳ máy khách của bạn. Bạn might muốn hạn chế quyền truy cập, chẳng hạn như chỉ truy cập một máy chủ nhất định từ một hoặc hai máy khách cụ thể. Điều này có thể được thực hiện với nhiều khóa máy khách, nhưng độ phức tạp cấu hình tăng theo phương trình bậc hai.

22
Tom Leek

Về cơ bản, tôi đang cố gắng phát triển một chiến lược cá nhân để đối phó với các cặp chính

Nếu bạn chịu trách nhiệm chính cho các máy chủ được đề cập, thì tôi khuyên bạn nên cân nhắc tìm kiếm các công cụ quản lý cấu hình như con rối/đầu bếp. Cả hai đều có phương pháp phân phối khóa SSH ra máy của bạn.

Những lý do tôi bắt đầu sử dụng con rối là đặc biệt vì tôi muốn một cách tốt để nhanh chóng thu hồi khóa trên ~ 60 máy chủ Linux của mình khi nhân viên thay đổi.

Khi bạn có một công cụ quản lý cấu hình để quản lý các khóa của mình, thì việc có nhiều cặp khóa trở nên dễ dàng hơn rất nhiều. Thay vì phải tự thu hồi khóa trên mỗi hộp hoặc thêm khóa mới vào mỗi hộp, bạn chỉ cần thêm khóa chung trên tổng thể cấu hình và khách hàng sẽ cập nhật danh sách ủy quyền trong bất kỳ khoảng thời gian bỏ phiếu nào bạn đặt cho quản lý cấu hình của mình dụng cụ.

Điều này không có nghĩa là bạn đang đặt nhiều niềm tin vào quản lý cấu hình của mình Máy chủ không bị xâm phạm. Bởi vì nó thường thực hiện các tác vụ với quyền root trên mọi máy bạn định cấu hình, nên bạn phải chắc chắn rằng nó được khóa chặt, có nhiều kiểm toán. Nếu kẻ tấn công thỏa hiệp với chủ cấu hình, thì nó có thể làm bất cứ điều gì như thêm khóa mới, thêm tài khoản mới, v.v.

10
Zoredache

Tôi đang sử dụng một khóa cho mỗi lĩnh vực và mỗi máy. 4 điều khiển từ xa được truy cập từ 2 máy trạm => 8 khóa riêng. Không bao giờ sao chép khóa riêng từ Máy chủ sang máy chủ khác. Nếu một máy trạm bị xâm nhập, hãy thu hồi tất cả các khóa đó.

Vì việc tạo khóa và định cấu hình SSH để sử dụng chúng khá tẻ nhạt, tôi đã viết một công cụ dành riêng để quản lý các khóa SSH của mình để truy cập Github: github-keygen .

0
dolmen