Là khóa một máy phát triển nhiều nỗ lực hơn giá trị của nó? [đóng cửa]


19

Đã làm việc như một nhà phát triển và quản trị viên / hỗ trợ CNTT cho nhóm phát triển, tôi đã gặp nhiều loại môi trường khác nhau từ hoàn toàn bị khóa đến hoàn toàn không. Theo kinh nghiệm hỗ trợ hạn chế của tôi, tôi nghĩ rằng đã ít nỗ lực hơn để hỗ trợ với một máy ít bị khóa hơn và tôi chắc chắn cảm thấy việc này dễ dàng hơn, nhưng tất nhiên điều này có thể là sai lệch. Tôi muốn biết quan điểm là gì từ góc độ hỗ trợ CNTT, có thực sự khó hơn để hỗ trợ các nhà phát triển không khóa máy không?


10
Với phân khúc lập trình viên lớn của dân số Server Fault từ Stack Overflow, tôi cá là điều này bị sai lệch lựa chọn. Nhà phát triển nào thực sự sẽ nói, 'Hãy khóa tôi lại, làm ơn!'?
romandas

Câu trả lời:


11

Vấn đề lớn nhất với việc không khóa máy phát triển là bất kỳ phần mềm nào họ phát triển sẽ yêu cầu toàn quyền quản trị viên để chạy. Quyền truy cập của nhà phát triển phải giống với môi trường mà họ sẽ cần chạy. Nếu họ cần "tự hỗ trợ" hoặc "tự cài đặt" thì hãy cung cấp cho họ một tài khoản quản trị khác, ví dụ Bruce.admin mà họ cần sử dụng khi làm quản trị viên công cụ, nhưng không được sử dụng hàng ngày.

Giống như không có quản trị viên UNIX nào xứng đáng với muối của họ sẽ sử dụng tài khoản root cho công việc không phải quản trị viên hàng ngày của họ.


14
Tôi phạm tội "sẽ yêu cầu". Bạn đang làm cho nó có vẻ như một kết luận bỏ qua rằng các nhà phát triển sẽ tự nhiên làm điều sai trái. Mặc dù tôi đồng ý rằng việc phát triển phần mềm chỉ chạy với các đặc quyền cao không cần thiết là ít hơn mong muốn, tôi không nghĩ CNTT nên cố gắng thực thi các thực tiễn phát triển cụ thể bằng các biện pháp khắc nghiệt như khóa máy. Nếu CNTT là một bên liên quan trong quá trình xác định các yêu cầu ứng dụng - và nó phải dành cho các ứng dụng nội bộ - thì hãy biến nó thành một ứng dụng yêu cầu được phát triển và thử nghiệm để chạy với các đặc quyền thấp hơn.
Chris W. Rea

Nhưng tôi nghĩ ý tưởng về một tài khoản riêng biệt có giá trị. Nhưng đừng ép buộc tôi, thế thôi.
Chris W. Rea

4
Trên Windows, tốt hơn là làm theo cách khác. Tạo tài khoản kiểm tra hoạt động với sự cho phép của người dùng chuẩn. Các ứng dụng có thể được kiểm tra bằng cách đăng nhập vào máy (hoặc VM) làm tài khoản người dùng thử nghiệm.
Mối quan tâmOfTunbridgeWells

3
Tôi đã hình thành ý kiến ​​"sẽ yêu cầu" dựa trên 15 năm kinh nghiệm kiểm tra kỹ thuật của tôi. Chắc chắn có những trường hợp ngoại lệ, nhưng phần lớn các ứng dụng trên windows không được thiết kế cho ít sự hiểu biết nhất và đó không phải là vì các nhà phát triển sẽ tự nhiên làm sai, đó là vì thực sự rất khó để thực hiện đúng.
Bruce McLeod

1
đã sử dụng như hàng ngàn ứng dụng khác nhau, chỉ 5% trong số đó cần quyền quản trị mà không có lý do thực sự.
Mircea Chirea

55

Hầu hết các nhà phát triển đều hiểu biết về kỹ thuật và biết họ đang làm gì. Họ thường cần cài đặt nhiều ứng dụng chuyên dụng, phải xin phép để làm điều này và đưa CNTT xuống và thêm nó có thể rất bực bội, đặc biệt là ở các công ty lớn hơn, cho cả hai bên.

Tôi đã tìm thấy những gì hoạt động tốt nhất là cho phép họ làm những gì họ muốn liên quan đến việc cài đặt phần mềm trên máy của họ, nhưng nếu họ gặp vấn đề với thứ gì đó chúng tôi không hỗ trợ, thì họ sẽ tự mình làm. Hầu hết các nhà phát triển đều hài lòng với điều này và dù sao họ cũng có thể tự chăm sóc máy của mình.

Khóa một ai đó trong kế toán để chỉ sử dụng IE và mở từ là tốt, nhưng nếu nhà phát triển của bạn cần cài đặt 4 loại trình duyệt khác nhau và cần nhanh chóng cài đặt một ứng dụng để giải quyết vấn đề, điều đó có thể gây phiền nhiễu.

Kinh nghiệm của tôi là các công ty có nhiều kiến ​​thức kỹ thuật, vì vậy các cửa hàng phát triển, nhà cung cấp CNTT, v.v., họ tin tưởng nhân viên của họ và để họ quyết định những gì họ muốn cài đặt sẽ hạnh phúc hơn và làm phiền CNTT ít hơn


10
Nếu tôi có thể bỏ phiếu cho câu trả lời này nhiều lần, tôi sẽ làm thế. Tôi là một nhà phát triển và đồng ý 110%. +1
Chris W. Rea

1
@ cwrea: Điều gì có thể vượt quá 10%?
setzamora

3
Tôi đồng ý, nhưng các công ty rất nghiêm ngặt về Bảo mật thông tin, sẽ không bao giờ cho phép các ứng dụng được cài đặt không phải là "tiêu chuẩn công ty"
setzamora

Vừa bị mất quyền Quản trị viên, tôi thấy mình gửi email cho bộ phận Hỗ trợ cứ sau nửa giờ để nhận được điều này, hoặc điều đó, hoặc thay đổi cài đặt này hoặc cài đặt đó. Một chủ đề phổ biến để kiểm tra ngày triển khai là nhấp đúp vào thời gian trong Khu vực thông báo. Một cái gì đó mà bây giờ tôi "không có cấp đặc quyền phù hợp" cho ... Nó đang khiến tôi phát điên!

1
Trong khi nói rằng 'nếu bạn gỡ cài đặt thì nó không được hỗ trợ' là tốt và tốt, thực tế nó biến thành một nhà phát triển phàn nàn với ông chủ của mình rằng phần mềm xyz không hoạt động và Systems / helpdesk sẽ không giúp tôi. Sếp bị bắn hạ bởi đồng nghiệp của mình, và điều tiếp theo bạn biết là Người quản lý / Giám đốc / VP đang hạ thấp người nào đó không quan tâm rằng nó không được hỗ trợ chỉ cần sửa chữa nó ngay bây giờ. Bây giờ Systems / Helpdesk phải hỗ trợ chương trình ngẫu nhiên xyz cho nhà phát triển a và chương trình ngẫu nhiên abc cho nhà phát triển b. Nếu bạn thực sự cần nó đặt nó thông qua các kênh.
Zypher

14

Xem bài đăng Stackoverflow này để biết một số tranh luận sôi nổi về giá trị của việc khóa các nhà phát triển. (Tuyên bố miễn trừ trách nhiệm: Tôi đã viết câu trả lời được chấp nhận).

Từ góc độ sysadmin, quyền truy cập vào hệ thống sản xuất rất nhạy cảm và bạn nên hạn chế quyền truy cập đó đối với những người cần nó để thực hiện công việc của họ (điều này có thể bao gồm các nhà phát triển có trách nhiệm hỗ trợ cấp 3 cho ứng dụng). Quyền quản trị cục bộ đối với PC phát triển hoặc máy chủ phát triển không ảnh hưởng đáng kể đến bảo mật hệ thống sản xuất của bạn.

Tạo một hình ảnh mà bạn có thể sử dụng để xây dựng lại các máy nếu cần thiết. Cài đặt thủ công phiên bản SQL Server dev, Visual Studio, Cygwin và MikTex cộng với một loạt các ứng dụng khác khá tốn thời gian. Một hình ảnh với các ứng dụng lớn này được cài đặt sẽ có giá trị hợp lý nếu bạn phải chụp lại hình ảnh của máy nhiều.

Từ góc độ phát triển, tôi thấy rằng tôi có thể khắc phục hầu hết các sự cố với máy và thường chỉ cần trợ giúp từ nhân viên hỗ trợ mạng trong những dịp khá hiếm. Các môi trường quá hạn chế có xu hướng tạo ra lưu lượng hỗ trợ phát triển giả để thực hiện công việc mà các nhà phát triển hoàn toàn có khả năng tự làm.

Một nơi khác mà các nhà phát triển có xu hướng cần rất nhiều công việc quản trị viên được thực hiện là trên các máy chủ cơ sở dữ liệu lưu trữ môi trường phát triển. Hầu hết các nhà phát triển có khả năng học các nhiệm vụ DBA thông thường một cách dễ dàng và dù sao cũng nên có kiến ​​thức làm việc về điều này (IMHO theo nguyên tắc). Chính sách truy cập quản trị viên quá hạn chế trên các máy chủ phát triển có thể thực hiện theo nhiều cách.

Một mạng lưới phát triển đầu là một ý tưởng tốt nếu nó có thể được sắp xếp - bạn có thể tường lửa này từ các máy chủ sản xuất của mình nếu cần thiết.

  • Khi các nhà phát triển có thể dễ dàng tái tạo cấu trúc của môi trường sản xuất, nó thúc đẩy văn hóa thử nghiệm triển khai trong đó thử nghiệm tích hợp có thể được tổng hợp mà không cần nhảy qua các vòng. Điều này sẽ có xu hướng cải thiện chất lượng phát hành và triển khai sản xuất.

  • Có thể mô phỏng một môi trường sản xuất cũng làm tăng nhận thức về các vấn đề triển khai và hỗ trợ sản xuất. Nó khuyến khích nhân viên phát triển nghĩ về cách ứng dụng có thể được hỗ trợ trong sản xuất, điều này có thể sẽ khuyến khích các kiến ​​trúc được xây dựng với ý tưởng này.

  • Nếu mạng này có bộ điều khiển miền, bạn có thể thiết lập mối quan hệ tin cậy để nó tin tưởng bộ điều khiển miền chính và tài khoản của nó. Mối quan hệ tin cậy này không cần phải có đi có lại, vì vậy nó không ảnh hưởng đến bảo mật cơ sở hạ tầng mạng sản xuất của bạn. Điều này có thể cho phép bạn có một mạng phát triển không tin cậy nhưng vẫn cho phép các nhà phát triển truy cập vào các tài nguyên được xác thực tên miền như tài khoản Exchange hoặc máy chủ tệp.

  • Bạn muốn các nhà phát triển có một phạm vi thử nghiệm hợp lý mà không cần phải vượt qua các vòng. Đặt các trở ngại chính trị trong con đường của công việc này có xu hướng khuyến khích các giải pháp thạch cao gắn bó về mặt chính trị nhưng tạo ra nợ kỹ thuật dài hạn (và thường không được công nhận). Là một sysadmin hoặc nhà phân tích hỗ trợ, hãy đoán xem ai sẽ nhặt được mảnh ...

Tôi sẽ thêm rằng đây không phải là một vấn đề trên môi trường unix hoặc linux; Người dùng có thể tùy chỉnh khá nhiều môi trường của họ từ họ .profile. Bạn có thể biên dịch và cài đặt những thứ trong /home/bloggsj/binthư mục của riêng bạn để thỏa thích. Rights Quyền quản trị cục bộ 'chủ yếu là vấn đề về cửa sổ, mặc dù vẫn còn một số điều cần truy cập root trong Unix.


Tôi muốn bình luận về điểm đạn cuối cùng của bạn. Bạn đề cập đến "những trở ngại chính trị" - xin lưu ý rằng mục đích ban đầu của thực tiễn bảo mật là bất cứ điều gì ngoài chính trị. Sau này nó có thể biến thành một thứ khác bởi vì tất cả các tổ chức cuối cùng có được những người tuân theo lá thư nhưng không có ý định của quy tắc - hoặc tệ hơn, biến những chính sách cao quý một thời thành phong kiến. Nhưng an ninh tốt và chính trị tốt CÓ THỂ đi đôi với nhau. Mặc dù vậy, phải mất những nỗ lực thiện chí từ mọi người có liên quan.
quux

Nói chung, chính sách được quản lý hợp lý sẽ không tạo ra loại trở ngại chính trị này, hoặc ít nhất sẽ không làm cho nó không thể vượt qua. Tuy nhiên, chính sách CNTT có xu hướng được phát triển theo sự cố và không phải lúc nào cũng là 'hợp lý'
Mối quan tâmOfTunbridgeWells

8

Tùy chọn hợp lý nhất mà tôi từng thấy (đã ở cả hai phía - và vẫn còn-) chỉ đơn giản là những thứ được mở khóa và cũng không được hỗ trợ . Cung cấp cho họ sự tự do, và nếu họ làm hỏng, tất cả những gì họ có thể nhận được là một sự phục hồi với một hình ảnh tiêu chuẩn .... Trong tình huống đó, tôi thấy đó là một kế hoạch tốt để đưa chúng vào một dạng mạng "không tin cậy" nào đó.

Theo như ý nghĩa (không) về việc khóa máy tính để bàn của nhà phát triển: Tôi khá chắc chắn rằng tất cả các khóa chỉ cản trở năng suất, hơn nữa, bất kỳ nhà phát triển có kỹ năng hợp lý nào cũng sẽ dễ dàng tìm thấy lỗ hổng ....


2
Tôi nhận được khoảng 20 phút hỗ trợ sau đó cung cấp một hình ảnh mới. Hoạt động tốt cho chúng tôi.
Tăng trước

6

Câu trả lời thực sự là: không có câu trả lời đơn giản hoặc không. Nhưng bảo mật ít nhất là quan trọng đối với người dùng dev của bạn như đối với bất kỳ ai khác.

Một mặt, có các nhà phát triển có xu hướng hiểu biết về kỹ thuật hơn. Mặt khác, công việc của họ thường là một công việc căng thẳng và các cột mốc dev của họ có thể được ưu tiên hơn sự chăm sóc thêm cần thiết để duy trì hệ thống của chính họ như một môi trường an toàn. Đây không phải là sự chỉ trích của các nhà phát triển; đó là một sự cân nhắc thẳng thắn về nhiệm vụ hàng ngày của họ.

Nếu bạn sẽ cung cấp cho các nhà phát triển quyền truy cập đầy đủ, không bị cản trở vào hệ thống của họ, thì bạn thực sự nên xem xét các biện pháp bổ sung sau:

  • Cung cấp một hệ thống khác, bị khóa nhiều như các hệ thống người dùng bình thường bị khóa, để sử dụng không phải dev thông thường.
    • Việc đưa các máy dev truy cập đầy đủ của họ vào một Vlan đặc biệt, chỉ có quyền truy cập vào các tài nguyên dev.
  • Hỏi xem nếu có bất cứ điều gì sẽ ngăn chặn một hệ thống bị nhiễm gây nguy hiểm cho cơ sở mã. Máy backdoor có thể kiểm tra mã ác tính hoặc xóa sạch cơ sở mã hóa trong tay của một tin tặc thù địch không? Thực hiện các bước thích hợp để giảm thiểu rủi ro này.
  • Tương tự, hãy hỏi nếu có bất cứ điều gì bảo vệ dữ liệu kinh doanh được giữ trong các hệ thống mà các nhà phát triển có quyền truy cập.
  • Thường xuyên làm kiểm kê phần mềm và kiểm toán bảo mật của các hệ thống dev.
    • Nhận ý tưởng về những gì họ đang chạy và sử dụng thông tin này để xây dựng hình ảnh triển khai hệ thống dev của bạn.
    • Sớm muộn gì bạn cũng sẽ có một nhà phát triển bất cẩn và cài đặt những thứ rõ ràng nguy hiểm hoặc hoàn toàn không liên quan đến công việc. Bằng cách gửi cảnh báo nhanh chóng khi điều này xảy ra, bạn sẽ cho cộng đồng nhà phát triển biết rằng có, ai đó đang theo dõi và họ có trách nhiệm tuân thủ các tiêu chuẩn hợp lý.
  • Bạn đang thực hiện quét phần mềm độc hại thường xuyên? Trong một số trường hợp, các nhà phát triển sẽ khiếu nại đúng về thuế hiệu suất được đánh thuế bởi các hệ thống AV truy cập (những hệ thống AV luôn bật, luôn quét trên mỗi lần truy cập tệp). Có thể nên chuyển sang chiến lược quét hàng đêm và / hoặc tạo loại trừ tệp / thư mục để quét khi truy cập của bạn. Tuy nhiên, hãy đảm bảo rằng các tệp bị loại trừ được quét theo một số cách khác.
    • Các nhà phát triển hỗ trợ quản trị viên của bạn có thể tắt tất cả chức năng quét AV không? Làm thế nào bạn sẽ phát hiện và khắc phục điều này?

Nếu bạn định khóa hệ thống dev, thì bạn nên xem xét những điều sau:

  • Bạn có khả năng hỗ trợ để trả lời các yêu cầu hỗ trợ của họ một cách nhanh chóng? Xem xét tỷ lệ thanh toán trung bình của các nhà phát triển của bạn và hỏi xem họ có xứng đáng với SLA thời gian phản hồi nhanh hơn hay không. Có lẽ không có ý nghĩa gì khi giữ nhà phát triển trị giá 120 nghìn đô la của bạn (người chủ chốt của dự án trị giá hàng triệu đô la) trong khi bạn đang xử lý các yêu cầu hỗ trợ từ nhân viên 60 nghìn đô la / năm.
  • Bạn có chính sách rõ ràng và rõ ràng về những yêu cầu hỗ trợ nào bạn sẽ và sẽ không phục vụ cho các nhà phát triển của bạn không? Nếu họ bắt đầu có cảm giác rằng sự hỗ trợ là tùy ý, cuối cùng bạn sẽ cảm thấy đau.

Dù bằng cách nào, bạn cũng cần phải thừa nhận rằng các nhà phát triển là một trường hợp đặc biệt và họ cần sự hỗ trợ thêm của một số loại. Nếu bạn không lập ngân sách cho việc này, các vấn đề có thể sẽ xảy ra ngay bây giờ ... hoặc sẽ có trong tương lai.

Một ghi chú bên lề, tôi đã thấy những cuộc tranh luận rất giống nhau diễn ra với sysadins. Trên ít nhất hai công việc khác nhau mà tôi thấy các sysadins tranh luận khá gay gắt khi có ý kiến ​​cho rằng chính họ nên khóa hệ thống hoặc ít nhất sử dụng hai thông tin đăng nhập (một với quyền riêng tư / quản trị viên; một không có). Nhiều sysadins cảm thấy rằng họ không nên bị khóa dưới bất kỳ hình thức nào và tranh cãi gay gắt chống lại các biện pháp như vậy. Sớm hay muộn một số quản trị viên không thích khóa sẽ có một sự cố bảo mật và ví dụ này sẽ có ảnh hưởng giáo dục đối với tất cả chúng ta.

Tôi đã từng là một trong những sysadins luôn luôn chạy với tư nhân quản trị viên. Khi tôi thực hiện thay đổi thành tài khoản kép và chỉ tăng khi có nhu cầu, tôi thừa nhận rằng điều đó khá bực bội trong vài tháng đầu. Nhưng lớp lót bạc trong đám mây là tôi đã học được nhiều hơn về tính bảo mật của các hệ thống tôi đang quản trị, khi tài khoản bình thường của tôi sống dưới cùng những hạn chế mà tôi đang đặt ra cho người dùng. Nó làm cho tôi một quản trị viên tốt hơn! Tôi nghi ngờ rằng điều tương tự cũng đúng với các nhà phát triển. Và may mắn thay trong thế giới Windows, chúng ta hiện có UAC, giúp dễ dàng chạy như một người dùng hạn chế và chỉ nâng lên khi cần thiết.

Cá nhân tôi không nghĩ rằng bất kỳ ai cũng nên ở trên một số hình thức thực hành bảo mật. Tất cả mọi người (sysadins, devs, quản lý cấp trên bao gồm) phải tuân thủ đủ các quy trình bảo mật và giám sát để giữ họ trên đầu. Nói cách khác là nói rằng các hệ thống và dữ liệu của công ty không đáng để nỗ lực bảo vệ.

Hãy đặt nó theo một cách khác. Nếu Mark Russinovich có thể được lấy bằng rootkit , bất kỳ ai cũng có thể!


3

Nếu bạn có một vài nhà phát triển, cách tiếp cận để cung cấp cho họ các máy chủ phát triển là một khả năng, nhưng nếu bạn có cả một tầng các nhà phát triển, thì tôi sẽ không cho họ bất kỳ quyền quản trị nào.

Vấn đề là bạn sẽ kết thúc với toàn bộ các nhà phát triển, mỗi người làm những gì họ làm, thường là hầu hết thậm chí không có ý thức bảo mật và chỉ muốn ứng dụng của họ hoạt động. Sau đó, bạn sẽ nhận được yêu cầu - "Chúng tôi đã hoàn thành giai đoạn phát triển, vui lòng sao chép môi trường dev của chúng tôi vào thử nghiệm, tiền sản xuất và sản phẩm".

Họ cũng có thói quen cài đặt rác ngẫu nhiên (phần mềm đóng gói kém) và sau đó ủy quyền cho bạn cài đặt nó trên hàng tá máy chủ trong các tầng khác.

Tôi làm cho chính sách khá đơn giản:

  • Các nhà phát triển KHÔNG được truy cập root - bao giờ - cho môi trường phát triển.
  • Các nhà phát triển có quyền truy cập root vào các máy chủ VMware tiền phát triển, nhưng KHÔNG hỗ trợ.
  • Các nhà phát triển phải cung cấp các gói RPM thuộc phân phối HĐH mà ứng dụng của họ sẽ chạy, các gói OR, RPM tuân thủ FHS và LSB.
  • Không ai trong số các ứng dụng của họ có thể chạy dưới quyền root
  • Sẽ không có quyền truy cập suhoặc sudocho người dùng ứng dụng - sẽ bị khóa để không có quyền truy cập shell. (Đây là dành cho kế toán / kiểm toán).
  • Bất kỳ lệnh nào họ cần phải chạy với quyền truy cập đặc quyền sẽ phải được yêu cầu và phê duyệt rõ ràng - tại thời điểm đó, nó sẽ được thêm vào sudoerstệp.
    • Không ai trong số các lệnh / script này sẽ được ghi bởi chúng.
    • Không có tập lệnh (trực tiếp hoặc gián tiếp) tham chiếu bởi các lệnh này sẽ được ghi bởi chúng.

Trên đây sẽ là trên hết, khiến họ suy nghĩ về những gì sẽ và sẽ không được phép khi đến lúc chuyển dự án lên các máy chủ thử nghiệm và ở trên.


2

Việc khóa máy của các nhà phát triển tốn nhiều công sức hơn giá trị của nó. Nó gây tổn hại nghiêm trọng đến năng suất vì bạn không thể làm bất cứ điều gì mà không có quyền quản trị. Tất nhiên, cuối cùng hệ thống sẽ trở nên rối tung, nhưng chắc chắn bộ phận CNTT của bạn không cung cấp hỗ trợ cho tất cả các công cụ của bên thứ 3 được sử dụng trong phát triển?

Vì vậy, như Vincent De Baere đã đề xuất, cách hành động tốt nhất sẽ chỉ là khôi phục hệ thống từ một hình ảnh, tất nhiên, môi trường phải được khôi phục sau đó, nhưng đó không phải là vấn đề của CNTT. Nếu điều đó xảy ra N lần bạn có thể đưa một người nói vào một loại "danh sách đen" và, vâng, bỏ quyền quản trị của anh ta trong một thời gian.

Dù bằng cách nào, môi trường nên được thiết lập theo cách chắc chắn rằng máy bị nhiễm (hoặc nói cách khác) không ảnh hưởng đến bất kỳ máy nào khác hoặc, nói, không gửi thư rác hoặc cái gì đó (ok, ngay bây giờ Tôi chỉ nói những điều rõ ràng, xin lỗi).


1

Chà, một phần có thể phụ thuộc vào môi trường bạn đang chạy (ví dụ Linux so với Windows); tuy nhiên, giả sử môi trường Windows, nó thường rắc rối hơn giá trị đơn giản vì một số phần mềm phát triển ngoài đó yêu cầu bạn phải có quyền nâng cao để hoạt động. Ví dụ: Visual Studio được biết là yêu cầu quyền của Quản trị viên , vì vậy, tôi không thấy lợi ích trong việc khiến ai đó nhảy qua vòng cho một phần công việc bắt buộc của họ.

Tuy nhiên, nếu công ty yêu cầu mọi thứ bị khóa thì đặt cược tốt nhất của bạn có khả năng cung cấp cho tất cả các nhà phát triển máy ảo trên hệ thống của họ mà họ có thể phát điên. thế giới (ví dụ như máy tính để bàn thông thường hạn chế và môi trường hoàn toàn tùy biến).

Cập nhật - Về phía Windows mọi thứ đáng chú ý hơn một chút, rõ ràng Visual Studio yêu cầu quyền Quản trị viên có một chút ngày và hiện có những cách rõ ràng để đặt quyền cần thiết (tệp PDF). Tuy nhiên, tôi không nghĩ rằng điều này thay đổi tùy chọn của tôi mà hầu hết các nhà phát triển mà tôi biết, bao gồm cả bản thân tôi, có xu hướng sử dụng các công cụ bổ sung ngoài Visual Studio và biết tất cả những gì họ cần về quyền có thể khó dự đoán.


Đúng là MS khuyến nghị VS2005 được chạy với tư cách Quản trị viên. Nhưng Michael Howard, một trong những nhân viên bảo mật phần mềm hàng đầu tại MS, nói rằng 99% thời gian nó hoạt động tốt như nonadmin: blog.msdn.com/michael_howard/archive/2007/01/04/ trộm ... Vì vậy, nếu vấn đề bảo mật đối với bạn, bạn có thể thử chạy nó không phải là phút. Một bất ngờ thú vị có thể đang chờ bạn!
quux

1

Tôi đồng ý với khái niệm sử dụng máy ảo trên máy tính để bàn bị hạn chế-

Trừ khi có yêu cầu khác, tôi cảm thấy thiết lập tốt nhất là một máy tính để bàn linux bị hạn chế với một vm miễn phí trên đầu trang. Linux giảm bớt chi phí cho tôi, một vm không chỉ là hệ điều hành mà họ muốn, mà còn được khôi phục để chụp nhanh hoặc sao lưu, và nói chung thế giới trông sáng hơn một chút khi không có nhiều thiết lập khác nhau cần ủng hộ.


+1 .. Tôi không hiểu tại sao máy ảo lại được sử dụng như vậy. Không chỉ cho mục đích mà bạn đã đề cập, mà việc phân phối phần mềm sẽ dễ dàng hơn nhiều khi sử dụng máy ảo.

1

Tôi (như một dev bản thân) thích có toàn quyền kiểm soát máy móc của tôi, có nghĩa là; chạy như admin khi cần.

Bạn có thể cung cấp đào tạo đặc biệt cho các nhà phát triển trước khi họ được phép truy cập đầy đủ vào máy tính của họ. Đặt một số quy tắc cho họ và có thể bạn có thể thực hiện kiểm toán mỗi lần một lần để thấy rằng họ tuân theo các thực tiễn tốt nhất.

Hầu hết họ sẽ cần biết thêm về cơ sở hạ tầng CNTT từ quan điểm hỗ trợ CNTT / quản trị viên CNTT, nội dung liên quan đến bảo mật cũng như lý do tại sao không phát triển với quyền nâng cao. (và làm thế nào để đảm bảo rằng bạn không ...)

"Đừng mù quáng tin tưởng chúng tôi khi chúng tôi nói với bạn rằng chúng tôi biết tất cả những gì chúng tôi cần biết về máy tính" ;-)

Bạn vẫn sẽ phải hỗ trợ họ với các công cụ kết nối mạng, tên miền và tài khoản, cài đặt phần mềm của các công cụ không phải là nhà phát triển, v.v.


Một điều nữa: Hãy chắc chắn rằng chúng tôi đã cài đặt AV thích hợp ... Buộc nếu cần ... ;-)
Arjan Einbu

1

Kinh nghiệm của tôi là với một nhóm người dùng chia đều giữa những người chỉ cần một máy bị khóa và những người khác (nhà phát triển, nhà khoa học), những người cần quyền truy cập quản trị viên. Họ là những người cao cấp đã sử dụng rất nhiều phần mềm khác nhau, một số nội bộ, một số thì không, nhưng rất nhiều phần mềm cần quản trị viên để chạy và công việc của họ yêu cầu họ sử dụng rất nhiều gói để mọi người có ý nghĩa nhất chính nó

Chúng tôi đã kết thúc với các quy trình sau:

  • Hình ảnh tiêu chuẩn của chúng tôi có các công cụ cơ bản: Windows, Office, Anti-virus, Acrobat, một vài tiện ích.
  • Chúng tôi đã cung cấp rất nhiều dung lượng đĩa mạng: đủ để mọi thứ có thể được lưu trữ trên mạng. Về ngoại lệ duy nhất là các tệp video đang xử lý phải ở cục bộ.
  • Nhân viên (tham khảo ý kiến ​​của người giám sát của họ) có hai lựa chọn: CNTT duy trì PC của họ, thực hiện tất cả các cài đặt và cấu hình HOẶC họ có thể có quyền truy cập quản trị viên để tự làm điều đó. Trong cả hai trường hợp, tất cả dữ liệu đã được sao lưu trên mạng.
  • Nếu CNTT bảo trì hệ thống và hệ thống bị chết, chúng tôi sẽ đưa nó trở lại trạng thái hiện có, bao gồm thêm phần mềm bổ sung mà họ cần mà chúng tôi đã cài đặt.
  • Nếu họ có quyền truy cập quản trị viên và hệ thống bị chết, chúng tôi sẽ xem xét và cố gắng khắc phục, nhưng cam kết của chúng tôi là đưa họ trở lại hình ảnh chuẩn và họ sẽ phải đưa nó từ đó. Nếu họ có bất kỳ dữ liệu cục bộ nào, trước tiên chúng tôi sẽ cố gắng loại bỏ dữ liệu đó, nhưng SLA của chúng tôi chỉ giúp họ có một PC hoạt động, tiêu chuẩn càng sớm càng tốt.
  • Bất kỳ ai cũng có quyền truy cập quản trị viên được yêu cầu biết cách đảm bảo các bản cập nhật Windows đang hoạt động, để luôn cập nhật phần mềm chống vi-rút và chống phần mềm độc hại.

Chúng tôi muốn đưa tất cả những người có quyền truy cập quản trị viên vào một vlan "không đáng tin cậy", nhưng chúng tôi không bao giờ có được điều đó.

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.