Làm cách nào để quản lý an toàn các khóa riêng cho các cặp khóa do EC2 quản lý?


8

Để khởi chạy một thể hiện EC2, bạn cần một cặp khóa. Làm thế nào để bạn xử lý tình huống một kỹ sư với sự cố với khóa riêng cho cặp khóa đó rời khỏi công ty? Nó có hoạt động để thêm quyền truy cập ssh riêng lẻ và hủy cấp phép cặp khóa ban đầu, ngay sau khi khởi chạy phiên bản không?


1
Tái triển khai các phiên bản mới của các phiên bản EC2 và loại bỏ các phiên bản cũ bằng cặp khóa cũ?
sdolgy

Câu trả lời:


10

Khi một nhân viên hoặc nhà thầu rời khỏi công ty, bạn cần phải vô hiệu hóa mọi quyền truy cập đặc quyền mà họ có đối với tài nguyên của công ty. Điều này bao gồm (nhưng không giới hạn) các mối quan tâm chính về ssh của bạn:

  1. Xóa khóa ssh công khai khỏi tất cả các tệp ủy quyền trên tất cả các phiên bản đang chạy. Thay thế chúng bằng một khóa ssh công khai mới được tạo ra chỉ dành cho những người nên có quyền truy cập.

  2. Xóa tất cả các mục nhập khóa trong EC2 mà người khởi hành đã biết để có thể bắt đầu các phiên bản mới với các khóa đó. Thay thế chúng bằng các mục khóa mới, có thể có cùng tên nếu

Phương pháp thay thế mà bạn đề xuất cũng tốt và là phương pháp tôi sử dụng: Vô hiệu hóa khóa ssh ban đầu và thêm các khóa ssh công khai riêng lẻ cho mỗi nhà phát triển để họ có thể đăng nhập bằng khóa ssh riêng thông thường. Điều này có thể được thực hiện để đăng nhập vào tài khoản dùng chung hoặc với mỗi nhà phát triển nhận tài khoản người dùng cá nhân của họ (ưu tiên của tôi).

Sau khi một nhân viên rời đi, bạn sẽ không chỉ phải dọn sạch các máy chủ đang chạy mà còn cả quá trình thêm các khóa ssh vào các máy chủ mới. Và, khi một nhân viên tham gia, bạn sẽ cần làm ngược lại: Thêm khóa ssh vào các máy chủ đang chạy và cập nhật quy trình máy chủ mới.

Đây có thể là một công việc nhiều hơn một chút để duy trì nhiều khóa ssh trên nhiều máy chủ, nhưng đó là nơi tự động hóa xuất hiện.


3

Bạn không bao giờ nên cung cấp khóa riêng này cho người dùng cuối. Người dùng cuối phải được cung cấp các phương tiện đăng nhập của riêng họ, chẳng hạn như xác thực khóa chung (sử dụng khóa riêng được bảo vệ bằng mật khẩu OWN của họ), sau đó là ủy quyền LDAP.

Việc phân phối khóa riêng do ec2 cung cấp cho bạn khiến người dùng không thể cung cấp. Đây chính xác là lý do tại sao việc sử dụng thông tin đăng nhập được chia sẻ hoàn toàn bị cấm bởi tất cả các quy định bảo mật và tuân thủ.

Khi bạn cho phép sử dụng thông tin đăng nhập được chia sẻ:

  • Không thể sử dụng nhật ký để biết ai thực sự / đang ở trên máy chủ
  • Không thể cung cấp lại người dùng mà không cung cấp lại tất cả người dùng (bao gồm cả truy cập khẩn cấp, đó là điều mà khóa riêng EC2 thực sự dành cho)

2

Xem tài liệu của Amazon về luân chuyển thông tin truy cập .

Sử dụng một cái gì đó như con rối hoặc tập lệnh ssh rắn để chạy xung quanh và thay thế tất cả các phiên bản của khóa cũ nếu bạn không muốn khởi chạy lại mọi thứ ... hoặc chỉ khởi chạy lại mọi thứ.


Tôi nghĩ rằng anh ấy không nói về các khóa tài khoản mà bạn có thể xoay mà nói thêm về khóa riêng .pem để đăng nhập vào ssh.

2
Đăng nhập ssh được kiểm soát bởi các mục ~ /. Trái_key. Những người ban đầu được gieo mầm bởi quá trình khởi động EC2, do đó cần phải sử dụng con rối hoặc kịch bản để thay thế chúng hoặc khởi chạy lại.
Jeff Ferland

ổn thỏa. Tôi không biết điều đó :).

Vâng đúng vậy. Đối với các tài khoản bình thường, tôi có thể có sshd sử dụng LDAP và do đó có thể hủy kích hoạt người dùng một lần từ LDAP. Nhưng các phím khởi chạy được quản lý bởi AWS. Vì vậy, tôi nghĩ rằng giải pháp bù nhìn / đầu bếp trong việc xóa khóa khởi chạy khỏi tệp ủy quyền của mỗi máy chủ là cách tốt nhất. Tôi nghĩ rằng tôi cũng muốn mỗi quản trị viên có khóa khởi chạy AWS của riêng họ, vì vậy tôi chỉ xóa một quyền truy cập của một người dùng tại một thời điểm.
Jeff

@Jeff Nếu SSH được cấu hình để tham chiếu LDAP và bỏ qua ủy quyền, thì khóa khởi chạy sẽ chỉ quan trọng đối với việc kiểm soát khởi chạy và chấm dứt cá thể. Điều đó phụ thuộc vào cách bạn xây dựng hình ảnh của bạn.
Jeff Ferland
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.