Có cách nào an toàn để lưu trữ mật khẩu được sử dụng cho ssh bởi một tập lệnh không?

Vì vậy, trước tiên, tôi biết, tôi nên sử dụng khóa auth với SSH. Không cần phải giải thích cho tôi điều đó.

Vấn đề ở đây là tôi có một nhóm máy chủ (lớn) và tôi cần có một kịch bản để có thể kết nối từng máy chủ.

Tôi sử dụng xác thực khóa bất cứ khi nào tôi có thể, tuy nhiên không thể thực hiện được trên mọi máy chủ (tôi không có quyền kiểm soát này). Vì vậy, SSH với đăng nhập, hoặc đôi khi telnet.

Vì vậy, đối với một số người tôi chỉ lưu trữ mật khẩu trong một db và tập lệnh của tôi sẽ lấy nó khi cần. Vấn đề là nó không thực sự an toàn để làm theo cách đó. Có cách nào để làm cho nó an toàn hơn một chút?

Giống như một số cách cụ thể của việc lưu trữ nó?

Nếu tập lệnh của bạn có thể kết nối với bất kỳ máy chủ nào, bất kỳ ai có quyền truy cập vào tập lệnh (hoặc quyền truy cập đặc quyền vào máy mà tập lệnh chạy trên) có thể kết nối với bất kỳ máy chủ nào trong số đó.

Nếu tập lệnh cần chạy tự động, tất cả các cược đã tắt. Câu trả lời ở đây là không, không có cách nào an toàn tuyệt đối để lưu trữ mật khẩu trong môi trường như vậy . Không có cách nào thực sự an toàn và thực tế để làm bất cứ điều gì.

Thay vì cố gắng tránh những điều không thể tránh khỏi, bạn nên tập trung vào phòng thủ theo chiều sâu .

Tất nhiên, bạn nên bảo vệ mật khẩu đầy đủ . Điều này thường có nghĩa là giữ chúng trong một tệp tách biệt với tập lệnh của bạn và định cấu hình quyền hệ thống tệp hạn chế . Đó là về tất cả những gì bạn có thể làm trong mặt trận này, từ góc độ bảo mật.

Các biện pháp khác chắc chắn có thể thêm sự tối nghĩa cho quá trình. Mã hóa mật khẩu sẽ khiến kẻ tấn công cần tìm kiếm khóa giải mã. Sử dụng một số loại lưu trữ được bảo vệ bởi hệ điều hành thường bảo vệ chống lại những người dùng khác truy cập khóa của bạn (vì vậy nó không mang lại lợi thế nào cho các quyền của hệ thống tệp, ngoài việc phức tạp để tấn công - và sử dụng). Những biện pháp này sẽ trì hoãn một cuộc tấn công, nhưng chắc chắn nhất là không ngăn chặn được nó trước một kẻ tấn công quyết tâm.

Bây giờ, hãy coi mật khẩu là công khai trong giây lát. Bạn có thể làm gì để giảm thiểu thiệt hại?

Một giải pháp cũ và đã được thử nghiệm là hạn chế những gì những thông tin đó có thể làm. Trên hệ thống UNIX, một cách tốt để làm điều này là thiết lập một người dùng riêng cho tập lệnh của bạn và giới hạn khả năng của người dùng đó , cả trên máy chủ truy cập và máy chủ truy cập. Bạn có thể giới hạn khả năng của người dùng ở cấp SSH , ở cấp độ vỏ hoặc có thể sử dụng cơ chế Kiểm soát truy cập bắt buộc như SELinux .

Một cái gì đó bạn cũng có thể muốn xem xét là để di chuyển logic script vào các máy chủ . Bằng cách đó, bạn có được một giao diện nhỏ hơn, dễ kiểm soát hơn và đặc biệt là ...

Giám sát . Luôn theo dõi truy cập vào các máy chủ. Tốt hơn là, xác thực nhật ký và các lệnh được thực hiện để ghi nhật ký chỉ . Đừng quên theo dõi các thay đổi tập tin bằng cách sử dụng auditd, ví dụ.

Tất nhiên, nhiều cơ chế trong số này không hữu ích nếu bạn không kiểm soát máy chủ, vì câu hỏi của bạn dường như ngụ ý. Nếu đó là trường hợp, tôi khuyên bạn nên liên hệ với những người quản trị máy chủ và cho họ biết về tập lệnh của bạn và các cạm bẫy bảo mật tiềm ẩn.

Câu trả lời ngắn gọn là không.

Câu trả lời dài là: Không, không có cách nào hoàn toàn an toàn. (Điều này bao gồm các biến môi trường, có thể được truy cập bởi những người khác trên máy chủ.) Cách gần nhất bạn có thể nhận được là lưu trữ chúng ở một số định dạng được mã hóa - keepass, tệp được mã hóa GPG hoặc một cái gì đó khác dọc theo các dòng đó. Nhưng đến một lúc nào đó bạn cần giải mã mật khẩu để tập lệnh của bạn có thể sử dụng nó, và tại thời điểm đó bạn sẽ dễ bị tổn thương.

Nói cách khác, bạn cần xem xét kỹ về bảo mật chuyên sâu, cả trên máy chủ mà tập lệnh được chạy, trên mạng và trên các máy chủ mục tiêu.

Bạn có thể mã hóa mật khẩu trong db của mình bằng mật khẩu thứ hai và lưu mật khẩu này trên một máy riêng (thứ 3) và có một hệ thống nơi tập lệnh cần mật khẩu ra khỏi db trước tiên kết nối với máy thứ 3 này để lấy mật khẩu giải mã , giải mã mật khẩu trong db bằng mật khẩu mà nó nhận được từ máy thứ 3 và nó hoạt động.

Tất nhiên, điều này không thực sự bổ sung thêm bất kỳ bảo mật nào, kẻ tấn công có đủ đặc quyền cũng có thể chỉ yêu cầu mật khẩu từ máy thứ 3.

Nhưng vấn đề là bên thứ 3 có thể điều khiển máy thứ 3, ví dụ: ông chủ hoặc nhân viên an ninh của bạn hoặc bên thứ 3 kiểm soát các máy chủ mà bạn không kiểm soát.

Bằng cách này, bạn có thể nói với họ, nếu họ gặp sự cố, nếu bạn nghỉ việc và họ không tin tưởng anh chàng thay thế bạn, hoặc họ chỉ muốn tập lệnh của bạn ngừng truy cập vào máy của họ, họ có thể rút phích cắm vào thứ 3 máy và tập lệnh của bạn sẽ không còn có quyền truy cập vào mật khẩu.