Thực tiễn và giải pháp tốt nhất để chia sẻ mật khẩu [đã đóng]


62

Chúng tôi có nhiều mật khẩu cần được biết đến với nhiều người trong công ty của chúng tôi. Ví dụ: mật khẩu quản trị viên cho các bộ định tuyến internet của chúng tôi, mật khẩu cho máy chủ web của chúng tôi và một vài mật khẩu "không phải CNTT" như mã an toàn.

Hiện tại, chúng tôi sử dụng một hệ thống "mật khẩu tiêu chuẩn" đặc biệt cho các hệ thống có giá trị thấp và chia sẻ mật khẩu bằng lời nói cho các hệ thống quan trọng hơn / có khả năng gây hại. Tôi nghĩ rằng hầu hết mọi người sẽ đồng ý rằng đây không phải là một hệ thống tốt.

Những gì chúng tôi muốn là một giải pháp phần mềm để lưu trữ mật khẩu "chia sẻ", với quyền truy cập cho mỗi giới hạn cho những người thực sự cần nó. Lý tưởng nhất, điều này sẽ nhắc, hoặc thực thi, thay đổi mật khẩu định kỳ. Nó cũng có thể chỉ ra ai có quyền truy cập vào một mật khẩu cụ thể ( ví dụ: ai biết mật khẩu gốc cho máy chủ XYZ?)

Bạn có thể đề xuất bất kỳ giải pháp phần mềm để lưu trữ và chia sẻ mật khẩu? Có điều gì đặc biệt để cảnh giác?

Thực tiễn phổ biến trong các công ty vừa và nhỏ cho việc này là gì?


Kiểm tra một số câu trả lời từ câu hỏi tương tự của tôi, mặc dù từ ngữ kém, câu hỏi: serverfault.com/questions/3696/iêu
boflynn

"Bạn có thể đề xuất bất kỳ giải pháp phần mềm nào để lưu trữ và chia sẻ mật khẩu không?" thuộc về trao đổi ngăn xếp khuyến nghị phần mềm .
Cristian Ciupitu

Câu trả lời:


26

Tôi phải đối mặt với vấn đề này mỗi khi tôi đến một khởi nghiệp mới. Điều đầu tiên tôi làm là tạo ra một vài "Mật khẩu an toàn" với một chương trình như thế này (hoặc một trong những dẫn xuất của nó):

http://passwordsafe.sourceforge.net/

Đặt kết hợp mạnh mẽ và ném chúng lên trên một chia sẻ mạng. Phân chia theo khu vực trách nhiệm ... cơ sở hạ tầng trung tâm, máy chủ sản xuất, dev / QA, v.v.

Khi đã có đủ động lực và giả sử tôi có các phụ thuộc môi trường Windows thích hợp, tôi muốn chuyển mọi người sang đây:

http://www.clickstudios.com.au/passwordstate.html

Nó có các tính năng cho cả thông tin cá nhân và chia sẻ.


Có một chương trình linux hoặc mac có thể đọc các tập tin passwordafe không? Sẽ thật tuyệt nếu có một giải pháp tốt cho một môi trường nơi mọi người sử dụng các hệ điều hành khác nhau. Điều tốt nhất tôi tìm thấy cho đến nay là các tệp văn bản được mã hóa gpg.
Đánh dấu


Tôi đã kiểm tra Passwordstate nhưng có vẻ khá hạn chế so với các giải pháp được trả tiền khác. Vì một điều, việc tra cứu mật khẩu không thể kiểm tra được. Tuy nhiên điều này sẽ có sẵn trong phiên bản tiếp theo.
Sergei

Có vẻ như Passwordstate có các tính năng kiểm toán hợp lý bây giờ. clickstudios.com.au/about/compliance-reporting.html
Nic

13

Không thể quên là cần phải có khả năng thu hồi mật khẩu nếu một nhân viên rời khỏi / bị sa thải. Đã có một số trường hợp được ghi nhận trên các phương tiện truyền thông phổ biến về nhân viên bị sa thải và 'quay trở lại' tại công ty của họ bằng mật khẩu vẫn còn hoạt động sau khi họ rời đi.

Đây thường là 2 phần:

  1. Biết tất cả các mật khẩu cần phải thay đổi (nếu không bạn mặc định là tất cả những mật khẩu tẻ nhạt)
  2. Tự thay đổi chúng hoặc tự động hóa quy trình với một công cụ hoặc tập lệnh.

Một yếu tố quan trọng khác là đảm bảo rằng chính sách mật khẩu được tuân thủ khi các thay đổi được thực hiện - ví dụ: làm thế nào để bạn biết rằng cùng một mật khẩu không được sử dụng trên nhiều tài khoản hoặc mật khẩu yếu không được sử dụng?


14
Chỉ là một quan sát, tôi đánh giá đây là một nhận xét, nhưng không phải là một câu trả lời, vì nó không giải quyết câu hỏi. Vẫn là một điểm tốt.
Kara Marfia

11

Tôi làm việc trong một cửa hàng CNTT nhỏ và chúng tôi đã sử dụng Máy chủ bí mật trong năm qua để quản lý mật khẩu cho các thiết bị mạng và nhu cầu của khách hàng.

Họ cung cấp một "phiên bản cài đặt" hoặc một phiên bản trực tuyến / được lưu trữ. Chúng tôi sử dụng phiên bản được lưu trữ với giá dưới 100 đô la / năm (5 người dùng) và có thể truy cập thông tin mật khẩu này một cách an toàn thông qua trình duyệt web bất cứ nơi nào chúng tôi đi. Nếu bạn thực sự lo lắng về bảo mật, hãy cài đặt nó trên máy chủ của riêng bạn và chỉ truy cập nó qua LAN hoặc VPN.

Ngoài ra, trình quản lý mật khẩu dựa trên web "cá nhân" yêu thích của tôi hiện cung cấp "phiên bản doanh nghiệp" - PassPack .

Tôi không chắc nó hoạt động như thế nào trong kịch bản này so với Secret Server nhưng một trong hai giải pháp phải linh hoạt và an toàn hơn nhiều so với các mẩu giấy, ứng dụng máy tính để bàn hoặc ( thở hổn hển ) ghi nhớ mọi thứ trong đầu bạn. Đối với mối quan tâm "một điểm thất bại", một trong hai sản phẩm này cho phép xuất dễ dàng sang CSV.




Máy chủ bí mật trông gọn gàng, nhưng nó không rẻ!
Toto

4

Tôi đã sử dụng LastPass được một thời gian và rất thích nó. Tôi đã dành một chút thời gian để nghiên cứu câu hỏi này vào năm ngoái và tôi thích cách LastPass đã thực hiện nó.

  • Tất cả thông tin được lưu trữ trên trang web của họ (và một bản sao cục bộ) trong một gói được mã hóa mà chỉ bạn mới có mật khẩu để giải mã
  • Tất cả mật khẩu đều có thể chia sẻ và có thể hủy bỏ, bạn thậm chí có thể chia sẻ chúng mà không cần cấp quyền truy cập vào mật khẩu (đối với thông tin đăng nhập web)
  • Plugin cho các trình duyệt chính
  • Nhiều tính năng khác

3

Tôi thứ hai đề xuất về Mật khẩu của Adam, với dữ liệu trên một thư mục mạng. Tôi có hai cân nhắc trong lĩnh vực này. Một là có một phiên bản duy nhất, để tất cả những ai cần dữ liệu đều nhận được dữ liệu hiện tại.

1- PasswordSafe sử dụng định dạng chuẩn cho tệp, do đó, có các giải pháp khác có thể đọc được, bao gồm KeePass.

2- Đặt tệp mật khẩu trên một chia sẻ an toàn và có một tập lệnh hàng đêm sao chép nó vào một vài vị trí trên mạng. Có lẽ sao chép nó vào một chia sẻ trên một máy chủ khác (ngoài trang web nếu có thể) và vào một ổ USB còn lại trong máy chủ. Bạn muốn tệp ít nhất một nơi không được bảo vệ bằng mật khẩu mà nó đang lưu trữ!

3- Lưu trữ trình cài đặt (hoặc phiên bản thực thi của chương trình) vào cùng một vị trí với tệp chính, để bạn có thể truy cập nhanh nếu cần.

4- Yêu cầu mọi người mở tệp CHỈ ĐỌC, trừ khi họ phải thay đổi.

5- Nếu cần, bạn có thể tạo nhiều tệp mật khẩu, một cho thông tin đăng nhập mà mọi người trong nhóm cần và một cho thông tin đăng nhập cho những điều thực sự nhạy cảm.

Tôi không khuyên bạn nên chuyển sang một giải pháp dựa trên web. Một giải pháp lưu trữ nội bộ có thể ổn, nhưng có vẻ như rất nhiều rắc rối. Tôi cũng lo ngại về việc nó là một điểm thất bại duy nhất.


2

Tôi chia sẻ trách nhiệm cho khá nhiều hệ thống với nhân viên của một trong những khách hàng của tôi. Chúng tôi đã đồng ý sử dụng lược đồ mật khẩu cho các tài khoản thường được sử dụng nhất. Các mật khẩu khác được lưu trữ trong một danh sách các cặp (số, mật khẩu) dựa trên giấy được duy trì bởi Trưởng phòng CNTT của khách hàng. Tên người dùng và máy chủ lưu trữ được lưu trữ trong cơ sở dữ liệu dễ truy cập. Mật khẩu được trao trên cơ sở cần biết.


2

Thực tiễn phổ biến trong các công ty vừa và nhỏ:

Ba nơi tôi đã làm việc đã sử dụng các tài liệu riêng biệt để chi tiết mật khẩu cho các hệ thống khác nhau. Một tài liệu cho các bộ định tuyến và tường lửa, một tài liệu khác để truy cập vào máy chủ và một tài liệu cho các nhà phát triển (ví dụ: chi tiết đăng nhập cho các kết nối cơ sở dữ liệu). Truy cập vào các ứng dụng có xu hướng không được ghi lại (tôi giả sử vì hầu hết bạn đăng nhập như chính mình với quyền quản trị viên).

Quản trị viên mạng chỉ nhìn thấy tài liệu mật khẩu bộ định tuyến và các cá nhân có quyền truy cập vào tài liệu này được liệt kê trong tệp này. Điều khoản về việc làm của họ nói rằng đăng nhập và mật khẩu mà họ có quyền truy cập là riêng tư và không được chia sẻ với người khác. Tương tự cho quản trị hệ thống và các nhà phát triển.

Thực tế đôi khi mật khẩu được chia sẻ, nhưng bạn có thể xác định ai cần biết (và tại sao) và thay đổi những gì cần thay đổi. Nó hoạt động tốt trong một công ty (phần mềm) gồm 50 nhân viên.


2

Đối với các mật khẩu hiếm khi được sử dụng như tài khoản quản trị viên cục bộ trên máy chủ, mật khẩu của bộ định tuyến và tường lửa và tương tự ở công việc cuối cùng của tôi, một cửa hàng khoảng 50 hoặc hơn, chỉ có sysadmin thực sự biết mật khẩu. Chúng được viết trên một tờ giấy trong một phong bì. Có tôi tin rằng ba phong bì đã được niêm phong và ký bởi Sếp, SysAdmin và Lập trình viên trưởng. Mỗi cá nhân đã có một bản sao của các tài liệu. Trong trường hợp mật khẩu được sử dụng, chúng tôi đã thay đổi chúng và tạo ra các phong bì mới.

Trong công việc hiện tại của tôi, tại một tổ chức lớn hơn nhiều, chúng tôi chỉ có 15 sysadins và vài nghìn người dùng chúng tôi có một phương pháp tính mật khẩu dựa trên tên máy chủ. Điều này bao gồm một tiền tố đã biết và một phương thức băm đủ đơn giản để thực hiện trên giấy. Khi mật khẩu cần thay đổi vì ai đó rời khỏi hoặc không chú ý, chúng tôi thay đổi tiền tố hoặc hàm băm hoặc cả hai. Bằng cách đó trong khi tôi không biết mật khẩu cho mọi máy hoặc thiết bị xung quanh mình, tôi có thể tính toán nó nếu tôi cần nó vì một số lý do.


ý tưởng gọn gàng, bạn có thể vui lòng cung cấp một ví dụ về một phương pháp băm dễ tính toán như vậy không?
Alexandar Ivanisevic

Bạn có thể sử dụng ROT aka mật mã Caesar, nhưng sử dụng một số được chọn ngẫu nhiên trong khoảng từ 1 đến 26 cho phần bù. Ví dụ: nếu máy chủ của bạn được đặt tên là fileserver2 và tiền tố là Le84D và phần bù là 18 thì mật khẩu sẽ là Le84Dxadwkwjnwj20
Laura Thomas


1

Tôi đã có cùng một vấn đề trước đây. Tôi đã kết thúc việc xây dựng một hệ thống để tự xử lý việc này. Nó lưu tên người dùng và mật khẩu ở dạng được mã hóa cao trong cơ sở dữ liệu với Giao diện web cho phép bạn nhập thông tin tài khoản và đặt bảo mật trên đó để chỉ những người hoặc nhóm chính xác mới có thể truy cập dữ liệu.

Nó đã không nhắc nhở khi đến lúc phải thay đổi mật khẩu vì các dịch vụ trên hàng chục máy chủ đã sử dụng cùng một thông tin đăng nhập và các thay đổi đối với mật khẩu phải được thiết lập trước.

Tôi đã xây dựng nó với tính năng kiểm toán đầy đủ để mỗi khi nhân viên nhìn vào đăng nhập, nó sẽ được ghi lại để chúng tôi có thể chuyển nhật ký kiểm toán sang Excel cho kiểm toán viên SOX.


1

Sử dụng GPG với tùy chọn Đối xứng để mã hóa tệp văn bản có tất cả mật khẩu trong đó. Sau đó, tất cả những gì bạn cần làm là cung cấp một cụm từ cho các quản trị viên khác. Khi quản trị viên rời công ty, sau đó chỉ cần mã hóa lại tệp văn bản bằng cụm từ mới.


... Và thay đổi tất cả mật khẩu trong đó, phải không?
Ingmar Hupp


1

Wow, chủ đề tốt! Không ai đề cập đến giải pháp ưa thích của tôi (ngoại trừ khi đi qua), vì vậy tôi sẽ hét to với KeePass. Có thể mở rộng, với xác thực dựa trên mật khẩu, khóa hoặc AD. Liệu công việc độc đáo cho chúng ta.


1
KeePassX cho phiên bản đa nền tảng ( keepassx.org )
Ingmar Hupp

1

Để truy cập máy chủ:

Cung cấp quyền truy cập vào một máy chủ và sử dụng nó như một hộp nhảy và quản lý các tài khoản trên hộp nhảy. Bất kỳ ai được coi là đáng tin cậy cho jumpbox đều được tin cậy vào tài nguyên từ xa. Bằng cách này, mọi người đều có mật khẩu riêng và mật khẩu trên máy chủ cho tài khoản cụ thể có thể được giữ bí mật.

Để truy cập các tài nguyên khác:

Giới hạn truy cập chỉ nhân sự cần thiết. Đảm bảo quản lý danh sách người dùng đáng tin cậy. Thay đổi mật khẩu cứ sau 90 ngày và cập nhật danh sách người dùng đáng tin cậy. Thông báo cho mọi người về sự thay đổi đang chờ xử lý trước 15, 7 và 1 ngày. Chỉ phân phối mật khẩu cho người quản lý và cho phép họ xác định ai cần truy cập. Sử dụng các tiện ích để đăng nhập truy cập và thường xuyên cho người dùng biết họ là các hệ thống được giám sát chặt chẽ. Bất kỳ doanh nghiệp hài hước trên các máy chủ nên là một hành vi phạm tội có thể kết thúc.


0

Tôi biết đây không phải là câu trả lời chính xác mà bạn muốn nhưng ở nơi làm việc của tôi hoàn toàn giống nhau, các nhân viên đáng tin cậy được cung cấp mật khẩu có liên quan, mật khẩu không được chia sẻ giữa các thiết bị và chúng không được ghi lại. Hệ thống có xu hướng hoạt động khá tốt vì việc quản trị các thiết bị thường là trách nhiệm của chỉ một vài thành viên của nhân viên. Chúng tôi cũng có một đội ngũ nhân viên rất tốt để có thể xây dựng lòng tin trong một khoảng thời gian dài.


0

Bạn có thể muốn sử dụng một số loại phần mềm vault mật khẩu - theo cách đó bạn có thể cung cấp cho người dùng được ủy quyền quyền truy cập của riêng họ vào đó và đảm bảo thông tin không bị rò rỉ bởi những người để lại ghi chú xung quanh. Một cái tốt có thể thậm chí không hiển thị mật khẩu, chỉ cần thả nó vào bảng tạm để cắt dán.


0

Chúng tôi có một hệ thống như Tổng thống và Bom - mỗi người hai người biết một nửa mật khẩu. Bằng cách đó, bạn sẽ không bao giờ gặp phải tình huống một quản trị viên lừa đảo đơn lẻ và tự mình thực hiện các thay đổi không được chấp thuận.


Thú vị ... nhưng không thực tế cho mã PIN cho thẻ tín dụng của công ty ;-)
Stewart

Điều này khá thú vị. Có nhiều trường hợp khi đồng nghiệp của tôi (với nửa kia của pw) và tôi không có ý định với nhau ... nhưng tôi thích ý tưởng này.
cop1152

1
Bây giờ bạn đã biến một điểm thất bại duy nhất thành một điểm thất bại kép. Điều này nhân đôi tỷ lệ cược rằng mật khẩu sẽ bị mất. Thêm vào đó, nó hoàn toàn không thực tế - tôi sẽ không bao giờ có thể hoàn thành bất cứ điều gì nếu tôi chỉ biết một nửa mật khẩu quản trị viên.
Aaron Brown

Tôi hy vọng bạn không có nghĩa là bạn sử dụng tài khoản quản trị chung ... không có dấu vết kiểm toán.
Maximus Minimus

0

Tôi làm việc trong một công ty CNTT, chúng tôi có nhiều khách hàng, thông thường chúng tôi giải quyết vấn đề từ xa. Chúng tôi sử dụng ssh để đăng nhập để khắc phục sự cố. Chúng tôi đã thêm một khóa ssh-key cho tất cả các máy khách của mình, vì vậy nó sẽ hữu ích cho người khác để đăng nhập và khắc phục sự cố, nếu tôi không ở đó. Nhưng máy mà chúng tôi đang sử dụng để đăng nhập vào máy khách rất cao bảo đảm. Nếu bạn muốn có mật khẩu tốt, tốt hơn nên sử dụng số và ký tự phụ.

Để thêm các phím ssh như sau:

1.ssh-keygen -t dsa (Để nhận các khóa ssh trên .ssh / id_dsa.pub

  1. scp .ssh / id_dsa.pub root @ remote: ~ / tmp

  2. Trên máy từ xa

mèo >> /tmp/id_dsa.pub .ssh / ủy quyền_keys2

Hãy thử đăng nhập để loại bỏ macine, từ bảng điều khiển khác ... :) chúc mừng sshhhhhh


-1

Từ chối sử dụng các hệ thống yêu cầu mật khẩu. Bất kỳ máy chủ nào cũng phải xác thực bằng các khóa SSH, bất kỳ trang web nào có OpenID. Chạy một nhà cung cấp OpenID bên trong tường lửa.

Rõ ràng, kịch bản này ngụ ý tất cả các hệ thống của bạn có thể truy cập thông qua SSH hoặc HTTP, nhưng nó hoạt động với chúng tôi.


Tôi không thấy cách thức hoạt động của bộ định tuyến, mã an toàn, mã PIN thẻ tín dụng, v.v.
Stewart

"Từ chối sử dụng các hệ thống yêu cầu mật khẩu" - có những thứ như PTB nên 'từ chối' không phải lúc nào cũng hoạt động ...
Sergei
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.