Các nhà phát triển nên có quyền quản trị viên trên PC của họ


135

Các nhà phát triển có nên có quyền quản trị viên trên PC của họ hay cung cấp cho họ quyền truy cập của người dùng đủ?

Một vài bình luận:

  • Nếu họ muốn dùng thử một số ứng dụng mới cần cài đặt, thì họ có thể dùng thử trên máy ảo và sau đó nhờ quản trị viên mạng cài đặt ứng dụng đó cho họ. Bạn có nghĩ nó sẽ hiệu quả không?
  • Có bất cứ điều gì mà nhà phát triển cần phải làm trên PC của họ sẽ yêu cầu quyền của quản trị viên không?

Chúng tôi là nhóm gồm 5 nhà phát triển và xây dựng các ứng dụng web


116
Nếu tôi bước vào một công việc và thấy rằng tôi không có quyền quản trị viên cho máy của mình, tôi sẽ không quay lại vào ngày hôm sau. Làm cho nhà phát triển của bạn sống dễ dàng hơn, không khó hơn.
annakata

29
Câu hỏi này sẽ bị sai lệch lựa chọn - có những lúc máy của nhà phát triển nên bị khóa, nhưng loại phản hồi đó sẽ không bao giờ được bình chọn trên một trang web dành cho nhà phát triển.
romandas

5
Ít phổ biến hơn người ta có thể nghĩ. Trong hầu hết các trường hợp, vấn đề cơ bản là dữ liệu nhạy cảm - ví dụ: luật bảo mật ngân hàng Thụy Sĩ có xu hướng ngăn cản các nhà phát triển xem dữ liệu khách hàng thực tế (đối chiếu tài khoản được để lại như một bài tập cho người đọc). Trong trường hợp này, vấn đề không phải là khóa máy mà là cung cấp các bộ dữ liệu được khử trùng cho công việc phát triển. Hầu hết các tình huống khác là các yêu cầu quy định (ví dụ: làm việc với dữ liệu được phân loại) hoặc CYA tự phục vụ.
Mối quan tâmOfTunbridgeWells

12
Tôi tự hỏi làm thế nào cùng một câu hỏi sẽ xuất hiện trên ServerFault ... (@romandas)
Ben Mosher

4
@BenMosher: đây là câu trả lời của bạn: serverfault.com/questions/232416/
kmote

Câu trả lời:


228

Câu trả lời là "Có". Các nhà phát triển sẽ cần phải cấu hình hệ thống để kiểm tra các mục, cài đặt phần mềm (nếu không có gì khác, để kiểm tra quá trình cài đặt của bất cứ điều gì họ đang phát triển), chọc vào sổ đăng ký và chạy phần mềm không hoạt động đúng nếu không có quyền quản trị viên (chỉ cần để liệt kê một vài mục). Có một loạt các nhiệm vụ khác không thể thiếu đối với công việc phát triển đòi hỏi phải có đặc quyền quản trị.

Lưu ý rằng nhân viên phát triển không nhất thiết phải có quyền truy cập root vào hệ thống sản xuất, quyền quản trị viên trên PC cục bộ không ảnh hưởng đáng kể đến bảo mật của hệ thống sản xuất. Hầu như không có lý do hoạt động hợp pháp nào để hạn chế quyền truy cập của quản trị viên vào các PC cục bộ cho nhân viên cần nó để thực hiện công việc của họ.

Tuy nhiên, lý do quan trọng nhất để cung cấp quyền truy cập quản trị là việc thiết lập môi trường phát triển tỷ lệ bị xâm phạm hoặc thứ hai sẽ gửi một thông điệp tới nhân viên phát triển của bạn:

'Chúng tôi đánh giá công việc của bạn quá ít đến nỗi chúng tôi sẵn sàng thỏa hiệp đáng kể khả năng thực hiện công việc của bạn mà không có lý do chính đáng. Trên thực tế, chúng tôi rất vui khi làm điều này để che đi cái mông của chính mình, thích thú với những ý thích bất chợt hoặc vì đơn giản là chúng tôi không thể bị làm phiền. Đó chỉ là trường hợp tốt nhất. Trường hợp xấu nhất là chúng tôi thực sự là kiểu người thích kiểm soát xem nó như là nhận thức của chúng tôi để cho bạn biết cách thực hiện công việc của bạn và những gì bạn làm hoặc không cần phải làm điều đó. Hãy làm những gì bạn đã cho và biết ơn rằng bạn đã có một công việc. '

Nói chung, việc cung cấp một môi trường làm việc hạng hai (huống chi là thiếu sót về cơ bản) cho nhân viên phát triển là một công thức cho hậu quả tự nhiên của việc chọc giận nhân viên của bạn - không có khả năng giữ người có năng lực, doanh thu nhân viên cao, tinh thần kém và giao hàng kém chất lượng. Đi ra khỏi con đường của bạn để làm như vậy - đặc biệt là nếu có một âm điệu gây rối cho ý thích quan liêu - chỉ là vô trách nhiệm.

Hãy nhớ rằng doanh thu nhân viên của bạn không chỉ phát sinh chi phí thay thế nhân viên. Chi phí nghiêm trọng nhất của doanh thu nhân viên là hầu hết những người gắn bó sẽ là gỗ chết không thể có được công việc tốt hơn. Theo thời gian điều này làm suy giảm khả năng của các bộ phận bị ảnh hưởng. Nếu ngành của bạn đủ gần, bạn cũng có thể thấy mình có được danh tiếng.

Một điểm cần lưu ý là các đặc quyền quản trị ít là vấn đề phát triển trên các hệ thống unix-oid hoặc máy tính lớn hơn so với trên Windows. Trên các nền tảng này, người dùng có thể làm nhiều hơn trong miền của mình mà không cần quyền toàn hệ thống. Bạn có thể vẫn muốn truy cập root hoặc sudo cho các nhà phát triển, nhưng không có điều này sẽ nhận được dưới chân ít thường xuyên hơn. Tính linh hoạt này là một lý do quan trọng nhưng ít được biết đến cho sự phổ biến liên tục của các hệ điều hành có nguồn gốc unix trong các trường Khoa học Máy tính.


3
Có một sự khác biệt với việc có quyền quản trị và chạy mọi thứ với quyền quản trị :) Nhiều nhà phát triển tất nhiên sẽ cần quyền quản trị. Nhưng chạy mọi thứ tương tác với quyền quản trị viên trên một hệ thống cục bộ không phải là đặc quyền tối thiểu. Nó mở ra cho các cuộc tấn công chống lại các hệ thống sản xuất mà nhà phát triển có quyền truy cập và một PC cục bộ bị xâm nhập cung cấp cho bất kỳ kẻ tấn công nào quyền truy cập tương tự. Điều này dễ hơn bạn nghĩ. Bảo mật là một vấn đề lớp trên lớp, đặc quyền tối thiểu cho mỗi quá trình và vấn đề đào tạo người dùng. Tôn trọng bảo mật của mọi thiết bị là cách duy nhất: vimeo.com/155683357
Oskar Duveborn

Tôi là người đề xuất trao quyền quản trị cục bộ cho nhà phát triển, nhưng nói rằng "quyền quản trị viên trên PC cục bộ không ảnh hưởng đáng kể đến bảo mật của hệ thống sản xuất" sẽ phụ thuộc vào môi trường của bạn. Điều mà hầu hết các nhân viên CNTT quan tâm là bạn sẽ cài đặt phần mềm chứa phần mềm độc hại / vi rút có thể lây lan khắp công ty hoặc nếu ai đó xâm phạm máy cục bộ của bạn và bạn có các tệp dữ liệu nhạy cảm được lưu trữ cục bộ hoặc trên cơ sở dữ liệu cục bộ. Trong một thế giới hoàn hảo, không có nhà phát triển nào có quyền truy cập vào các tệp dữ liệu HIPAA / PCI và tất cả các cơ sở dữ liệu dev đều được xóa sạch, nhưng chúng tôi biết đây không phải là trường hợp.
L_7337

87

Các nhà phát triển nên có toàn quyền và toàn quyền kiểm soát máy họ đang sử dụng. Hầu hết các công cụ gỡ lỗi đều yêu cầu quyền của quản trị viên để kết nối với thời gian chạy của ứng dụng mà họ đang xây dựng.

Hơn nữa, các nhà phát triển thường xuyên tải xuống và thử những điều mới. Thêm các bước bổ sung như cần một quản trị viên mạng đến và cài đặt một cái gì đó cho họ chỉ đơn giản là làm thất vọng nhà phát triển và sẽ nhanh chóng biến cuộc sống thành địa ngục cho người làm việc trên mạng.

Điều đó nói rằng, họ nên là một quản trị viên trên hộp THEIR, không phải mạng.


5
Vấn đề lớn nhất mà tôi gặp phải với các nhà phát triển có quyền quản trị là bạn đã được cấp các quyền bạn có trên tài nguyên máy tính cục bộ của mình. Quá nhiều kết quả phần mềm tào lao - ghi vào C: \ Chương trình tệp, ghi vào HKLM, v.v. Trên máy trạm của bạn, có thể, nhưng yêu cầu thử nghiệm ở nơi bạn không.
SqlRyan

4
@rwmnau: Điều đó không áp dụng cho phát triển web. Ngoài ra, vấn đề trở nên rõ ràng khá nhanh khi QA dưới quyền bình thường.
NotMe

2
Làm cho máy ảo có sẵn và đăng nhập dev-test mà không có đặc quyền của quản trị viên là một cách tốt để tạo điều kiện kiểm tra phần mềm sẽ chạy với quyền người dùng thông thường.
Mối quan tâmOfTunbridgeWells

Phần mềm được phát hành với các quyền chỉ dành cho quản trị viên đã trải qua quá trình QA cực kỳ kém (hoặc không có). Phần mềm nên được kiểm tra trong môi trường thực tế, do đó QA nên nắm bắt sớm và vấn đề bị các nhà phát triển bỏ qua sẽ được khắc phục. Đúng?

2
@rwmnau - Bất kỳ nhà phát triển nào xứng đáng với muối của họ đều hoàn toàn nhận thức được điều này nhưng câu trả lời không phải là khóa máy dev của họ. Đó là cung cấp cho họ một môi trường thử nghiệm để họ có thể triển khai dự án của mình một cách thuận tiện để giải quyết các vấn đề này.
Spencer Ruport

48

Có và không.

Có, nó tiết kiệm rất nhiều thời gian làm phiền hỗ trợ hệ thống.

Không, người dùng của bạn không có nó vì vậy đừng tin vào điều đó.

Chúng tôi phát triển với quyền quản trị và kiểm tra mà không có. Mà làm việc ra ngay.


11
Vợ tôi đã phải tranh luận về một tài khoản không phải quản trị viên trên máy tính của cô ấy, vì vậy cô ấy có thể chắc chắn rằng người dùng có thể làm những gì cô ấy có thể. Chính sách của bạn là hoàn toàn chính xác (và do đó được nâng cấp).
David Thornley

1
Chính xác, dev nên có admin, test và QA nên có user.
Tiến sĩ Watson

Tôi không thể đồng ý với bạn nhiều hơn! Quyền truy cập của quản trị viên rất tốt cho việc phát triển, nhưng hầu hết người dùng sẽ không có nó (nếu bạn phát triển phần mềm công ty ... CNTT thường khóa mọi thứ khá tốt).
Pulsehead

18

Quản trị viên địa phương có, cho tất cả các lý do nêu trên. Quản trị mạng không, bởi vì chắc chắn họ sẽ bị lôi kéo vào các nhiệm vụ quản trị mạng vì "họ có thể". Devs nên được phát triển. Quản trị mạng là một công việc hoàn toàn khác.


15

Các nhà phát triển thường cần phải làm những việc mà người bình thường sẽ không làm, và thông thường nên có tài khoản quản trị viên. Làm cho họ nhảy qua những cái vòng vụng về làm lãng phí thời gian của họ và làm mất tinh thần họ. Có thể có ngoại lệ trong các tình huống bảo mật cao, nhưng nếu bạn không thể tin tưởng ai đó bằng tài khoản quản trị viên, bạn chắc chắn không thể tin tưởng vào mã của họ.

Họ cũng nên có một tài khoản có cùng quyền với người dùng của họ (nhiều hơn một tài khoản nếu nhóm người dùng có trạng thái cấp phép khác nhau). Mặt khác, họ có thể phát triển thứ gì đó hay ho, triển khai nó và sau đó thấy nó không hoạt động cho người dùng.

Cũng có quá nhiều cách để làm hỏng máy tính bằng tài khoản quản trị viên (vâng, tôi đã thực hiện nó). Bộ phận CNTT cần một chính sách rằng họ sẽ tái hiện hình ảnh máy tính của nhà phát triển nếu họ không thể khắc phục nhanh chóng. Tại một nơi tôi ký hợp đồng, tôi đã phải ký một bản sao của chính sách đó để có được tài khoản quản trị viên của mình.

Đây là một câu trả lời khá cụ thể của Windows. Trong Linux và các hệ thống Unix-y khác, các nhà phát triển thường chỉ có thể sử dụng tài khoản người dùng, thường không cần một tài khoản khác để kiểm tra (nếu họ có tài khoản họ có thể sudo, họ biết khi họ đang sử dụng sudo, nhưng họ có thể cần một quyền với cùng một nhóm) và có thể gây ra thiệt hại đáng kinh ngạc cho HĐH rất dễ dàng, vì vậy chính sách CNTT tương tự là cần thiết.


4
"Có thể có ngoại lệ trong các tình huống bảo mật cao, nhưng nếu bạn không thể tin tưởng ai đó bằng tài khoản quản trị viên, bạn chắc chắn không thể tin vào mã của họ." - đó là một suy nghĩ tuyệt vời, cảm ơn bạn!
Người dùng

Bạn cũng không thể tin tưởng mã: bạn nên thực hiện mã được đánh giá ngang hàng cho mọi thứ. Và tôi nghĩ điều đó cũng có ý nghĩa đối với việc cài đặt: hãy nhờ ai đó đánh giá ngang hàng. Phần mềm họ sắp cài đặt.
Tim

10

Có, Half-Life 1 (và tất cả các mod liên quan: phản đòn, ngày thất bại, v.v.) cần quyền quản trị viên (ít nhất là cho lần chạy đầu tiên, tôi nghĩ) để hoạt động chính xác trong Windows NT, 2000, XP, v.v. .

Và, loại nhà phát triển nào không chơi Counter Strike vào giờ ăn trưa? (chắc chắn là một thứ nhảm nhí)


10

Chịu đựng nỗi đau khi phải phát triển mà không có quyền quản trị trên máy, câu trả lời của tôi chỉ có thể là có, đó là điều cần thiết.


8

Chắc chắn rồi! Làm thế nào khác tôi sẽ cài đặt trình quản lý tải xuống để tải phim vào ban đêm?

Đôi khi các nhà phát triển thực sự cần phải cài đặt mọi thứ hoặc thay đổi một cái gì đó trong hệ thống để kiểm tra một số ý tưởng. Sẽ là không thể nếu bạn phải gọi cho quản trị viên mỗi khi bạn cần thay đổi điều gì đó.

Tôi cũng có quan sát cá nhân rằng một số quản trị viên có xu hướng vặn chặt tất cả những gì có thể để làm cho ngay cả những điều nhỏ nhặt phụ thuộc vào họ hàng ngày, do đó ... cái gì, đảm bảo công việc của họ? chọc giận những người dùng khác? Không có câu trả lời. Nhưng lẽ thường không thấy ở đây.

Lần trước có một vấn đề với PC của tôi, tôi đã tham gia khôi phục hệ thống, đưa ra một số gợi ý làm việc trong nhóm với quản trị viên, hoặc vì vậy tôi nghĩ rằng ... Admin đã rất tức giận và cáo buộc tôi cố gắng dạy anh ta hoặc xác định lại các quy tắc. Tôi cho rằng đó chỉ là bản ngã của anh ấy khi anh ấy không thấy điều đó tuyệt vời trong phòng của chúng tôi giữa các đồng nghiệp khác.


Tôi không thể đồng ý nhiều hơn. Sau khi trở thành một thợ sửa chữa hệ thống trong 6 năm, thật đau đớn khi phải gọi cho bộ phận trợ giúp để sửa lỗi.
Matthew Whited

8

Câu trả lời là, nhà phát triển nên có 2 máy !!

  • Một phát triển có quyền quản trị viên, đủ sức mạnh, bộ nhớ, kích thước màn hình và tính di động và các đặc quyền ADMIN, với phần mềm chống vi-rút của công ty được nhà phát triển tải nhưng có thể định cấu hình khi được yêu cầu với chính sách tự động ..

  • Một công ty có tải công ty, chính sách, đặc quyền người dùng không phải quản trị viên, v.v ... Nhà phát triển có thể sử dụng ứng dụng này cho các ứng dụng chế độ phát hành thử nghiệm đơn vị vì một số nhà phát triển có thói quen khó chịu khi thực hiện tất cả thử nghiệm đơn vị với đặc quyền của quản trị viên.


9
Ý tưởng tuyệt vời ... nhưng hầu hết các công ty thậm chí sẽ không cung cấp cho bạn một cỗ máy "tốt".
Matthew Whited

1
Bạn có thể thực hiện máy thứ hai trong máy ảo với bản dựng 'tiêu chuẩn'. Điều này đặc biệt hữu ích nếu mạng phát triển được tách ra trên miền riêng của nó. Một VM sản xuất riêng biệt trên miền chính cung cấp cho các nhà phát triển quyền truy cập vào tài nguyên mạng.
Mối quan tâmOfTunbridgeWells

5

Nếu bạn đảo ngược câu hỏi tôi nghĩ nó trở nên dễ trả lời hơn; chúng ta có nên xóa quyền quản trị viên khỏi nhà phát triển không? Lợi ích là gì?

Nhưng thật ra, tôi nghĩ câu trả lời phụ thuộc vào bối cảnh, môi trường của bạn. Khởi nghiệp nhỏ sẽ có câu trả lời khác với cơ quan chính phủ được chứng nhận ISO.


5

Có, nhưng họ cần nhận thức được những hạn chế mà người dùng của họ sẽ gặp phải khi chạy phần mềm trong môi trường hạn chế hơn. Các nhà phát triển nên dễ dàng truy cập vào các môi trường "điển hình" với các nguồn lực và quyền hạn chế. Trước đây, tôi đã kết hợp triển khai các bản dựng cho một trong những hệ thống "điển hình" này (thường là VM trên máy trạm của riêng tôi) như một phần của quy trình xây dựng, để tôi luôn có thể cảm nhận nhanh về cách phần mềm hoạt động trên phần cuối máy của người dùng.

Các lập trình viên cũng có trách nhiệm phải biết các quy tắc viết phần mềm khó và nhanh cho người dùng không phải là quản trị viên. Họ nên biết chính xác tài nguyên hệ thống nào họ luôn được phép (hoặc cấm) truy cập. Họ nên biết các API được sử dụng để có được các tài nguyên này.

"Nó hoạt động trên máy của tôi" không bao giờ là một cái cớ!


5

Là quản trị viên hệ thống, tôi là tất cả cho các nhà phát triển có quyền quản trị cục bộ trên máy trạm của họ. Khi có thể, bạn không nên làm hầu hết mọi việc với tài khoản 'người dùng' tiêu chuẩn và sau đó sử dụng tài khoản 'quản trị viên khác để thay đổi, cài đặt ứng dụng, v.v. Thường thì bạn có thể sudo hoặc runas để thực hiện những gì bạn muốn mà không cần đăng nhập ngoài. Nó cũng hữu ích để nhắc nhở chúng tôi về những gì bảo mật gây tổn hại cho người dùng cuối sẽ phải vượt qua khi phát hành sản xuất.

Bên cạnh đó, bạn cũng nên có một hệ thống [sạch] hoặc VM (s) để bạn có thể kiểm tra mọi thứ đúng cách và không rơi vào tình huống "nó trông / hoạt động tốt trên hệ thống của tôi" do điều chỉnh hệ thống.


3

Không có người dùng điện

Trước hết, Power User về cơ bản là quản trị viên - vì vậy " giới hạn " người dùng đối với Power User không cung cấp bất kỳ sự gia tăng nào về bảo mật cho hệ thống - bạn cũng có thể là quản trị viên.

Đăng nhập tương tác như một người dùng bình thường

Thứ hai, tất nhiên nhà phát triển cần quyền truy cập quản trị vào máy phát triển của họ (và máy chủ và hộp thứ hai, v.v.) nhưng tất nhiên không ai nên tương tác đăng nhập với tư cách quản trị viên trong quá trình phát triển hoặc kiểm tra bình thường. Sử dụng tài khoản người dùng bình thường cho điều này và hầu hết các ứng dụng.

Bạn thực sự không muốn chạy [chèn bất kỳ trình duyệt, plugin, IM, ứng dụng khách email nào, v.v.) với tư cách quản trị viên.

Bạn thường không đăng nhập vào hộp Linux của mình dưới dạng root, ngay cả khi bạn có thể có quyền truy cập root khi bạn cần.

Sử dụng tài khoản quản trị viên cá nhân riêng biệt

Cung cấp cho nhà phát triển một tài khoản quản trị viên cá nhân riêng biệt cho máy của anh ấy (tốt nhất là tài khoản miền) cũng là quản trị viên hợp lệ trên các máy chủ dev / test khác và các hộp mà người đó cần truy cập quản trị.

Sử dụng "chạy như" và trong Vista + UAC để nhắc hoặc yêu cầu nhắc và nhập thông tin đăng nhập quản trị cho các tác vụ và quy trình chỉ khi cần. PKI với thẻ thông minh hoặc tương tự có thể làm giảm đáng kể sự căng thẳng trong việc nhập thông tin đăng nhập thường xuyên.

Mọi người đều vui vẻ (hoặc ?;)

Sau đó kiểm toán truy cập. Bằng cách này, có thể truy xuất nguồn gốc và một cách dễ dàng để tìm ra ai đang sử dụng các phiên dịch vụ đầu cuối trên một máy chủ dev / test cụ thể mà bạn phải truy cập ngay bây giờ ...

Được cấp, chắc chắn công việc phát triển sẽ không bao giờ yêu cầu đặc quyền của quản trị viên cục bộ - như hầu hết phát triển web nơi thử nghiệm triển khai trên một máy chủ hoặc máy ảo riêng biệt và nơi cassini hoặc bất cứ thứ gì được sử dụng để gỡ lỗi cục bộ thực sự chạy tốt như người dùng bình thường.


2
Bạn đang nói: không cho phép họ đăng nhập với tư cách quản trị viên, nhưng cung cấp cho họ các khóa chỉ trong trường hợp họ cần làm điều gì đó yêu cầu. Tôi đã đọc những tin tào lao tương tự trên trang web của MS về UAC và nó cho thấy sự thiếu cân nhắc thực sự về hàng trăm việc mà một nhà phát triển làm trong một ngày.
NotMe

2
UAC được đưa vào để ngăn người bình thường tự bắn vào chân mình. Nếu một dev làm điều này, xấu hổ về anh ta. Nếu anh ta liên tục làm điều đó thì anh ta cần phải tìm một dòng công việc khác.
NotMe

Nếu bạn cung cấp cho họ các khóa bạn thực sự "cho phép" họ, chúng tôi, sẽ đăng nhập với tư cách quản trị viên. Chỉ là nó không bao giờ là một ý tưởng tốt để làm điều đó cho các công việc hàng ngày. Tại sao mọi người vẫn nghĩ rằng điều này là bình thường hoặc cần thiết chỉ vì họ là chuyên viên máy tính, lập trình viên hoặc quản trị viên vượt xa tôi.
Oskar Duveborn

Nếu bạn từng thấy những gì một quản trị viên hệ thống hiện đại làm trong một ngày, bạn sẽ nhận ra rằng nhu cầu truy cập quản trị và nhập thông tin đăng nhập thay thế cao hơn bất kỳ trình mã hóa cấp hệ thống khó tính nào từng thấy. Họ vẫn không đăng nhập với tư cách quản trị viên cho các nhiệm vụ hàng ngày và làm tốt.
Oskar Duveborn

Bạn thường không đăng nhập với quyền root vào hệ thống unix ngay cả khi bạn quản trị nó, vậy tại sao bạn lại làm như vậy trên hệ thống Windows, ngay cả khi bạn là nhà phát triển? Điều đó không có ý nghĩa. Chạy tất cả các ứng dụng ngẫu nhiên như Skype hoặc không có đặc quyền hệ thống cao là không biết nói gì - bạn chỉ nâng cao các ứng dụng cần nó.
Oskar Duveborn

3

Tôi làm việc chủ yếu trong thế giới * nix và mô hình tiêu chuẩn dành cho các nhà phát triển để làm việc trong một tài khoản người dùng bình thường, không có đặc quyền với khả năng (thông qua sudohoặc su) để leo thang lên các đặc quyền của quản trị viên khi cần thiết.

Tôi không chắc cách sắp xếp Windows tương đương sẽ là gì, nhưng theo kinh nghiệm của tôi, đây là thiết lập lý tưởng:

  • Một mặt, việc có quyền quản trị viên theo yêu cầu giúp nhà phát triển có toàn quyền đối với máy trạm của mình khi cần.

  • Mặt khác, phần mềm Windows có một lịch sử lâu dài, giả sử rằng tất cả người dùng đều có quyền quản trị, đến mức nhiều chương trình sẽ không chạy cho người dùng không phải là quản trị viên. Nhiều vấn đề bảo mật của Windows xuất phát trực tiếp từ yêu cầu ngầm này rằng, để có thể sử dụng máy tính một cách đáng tin cậy, tất cả người dùng phải là quản trị viên. Điều này phải thay đổi và cách hiệu quả nhất để đảm bảo rằng phần mềm của bạn sẽ chạy cho người dùng không phải quản trị viên là để các nhà phát triển của bạn tự chạy nó với tư cách là người dùng không phải quản trị viên.


Tôi không nghĩ rằng tôi đã gặp một ứng dụng kinh doanh không thể chạy như một người dùng bình thường trong 5-10 năm qua. Khi tôi còn là BOFH và tất cả người dùng ở đó đã buộc phải chạy mọi thứ như người dùng bình thường kể từ ~ 2001 thực sự - không có tư nhân quản trị nào được ủy quyền và nó hoạt động độc đáo và ngăn chặn rất nhiều phần mềm độc hại thời đó. Ngoài ra còn có các miếng chêm tự động được áp dụng trong các phiên bản Windows gần đây hơn nếu ứng dụng cũ đó được chạy (đánh lừa nó trong hộp cát) và trong công việc phát triển hàng ngày của tôi, chỉ có Visual Studio mới được nâng lên khi tôi cần đính kèm để các quá trình khác để gỡ lỗi.
Oskar Duveborn

3

[xin lỗi tiếng anh không phải là tiếng mẹ đẻ của tôi, làm hết sức mình :)] Vâng,

Trải nghiệm cá nhân (Tôi là nhà phát triển c ++ / SQL):

Tôi đã từng là quản trị viên của máy tính windows trong công việc trước đây của tôi. Tôi cũng có quyền dbo (không phải dba) trên cơ sở dữ liệu, bao gồm cả cơ sở dữ liệu môi trường sản xuất. Trong 2 năm rưỡi với 8 người có những quyền cao điên rồ này ... chúng tôi chưa bao giờ gặp rắc rối nào. Trên thực tế, chúng tôi đã giải quyết rất nhiều vấn đề bằng cách cập nhật db thủ công. Chúng tôi có thể làm nhiều thứ thực sự nhanh chóng cho các bản sửa lỗi nóng và nhà phát triển.

Bây giờ tôi đã thay đổi công việc. Tôi đã quản lý (khóc rất nhiều) để trở thành quản trị viên của máy windows của mình. Nhưng máy chủ dev là một máy chủ mũ đỏ mà chúng tôi kết nối bằng ssh. Cố gắng cài đặt Qt là một cực hình, giới hạn hạn ngạch, giới hạn không gian, quyền thực thi và quyền viết. Cuối cùng chúng tôi đã từ bỏ và yêu cầu quản trị viên làm điều đó cho chúng tôi. 2 tuần sau vẫn không có gì được cài đặt. Tôi đang trở nên rất nhanh khi đọc báo và nhấn alt +.

Tôi yêu cầu quyền quản trị, vì chỉ có nhà phát triển phần mềm của tôi sử dụng máy này.

-> Trả lời: "Nếu có các quy trình, bạn không nên làm bất cứ điều gì bạn muốn. Nó phải chạy tốt một lần trong prod".

-> Cố gắng giải thích với người quản lý không có kỹ thuật: "Tôi sẽ không có quyền quản trị viên trong môi trường sản xuất hoặc UAT. Nhưng máy dev của tôi thì khác. Nếu tôi làm ghế thay vì phần mềm, bạn có thể nói với tôi rằng tôi có thể Tôi không đặt bất kỳ công cụ nào tôi muốn trong xưởng của mình vì xưởng của tôi cần trông giống như nơi chiếc ghế sẽ được sử dụng? Tôi đưa một gói thực thi cho uat. Các lib và công cụ tôi sử dụng để xây dựng chúng là vô hình cho người dùng cuối hoặc anh chàng cài đặt gói. "

Tôi vẫn đang đợi ngày hôm nay. Tôi tìm thấy một giải pháp, mở một môi trường dev, đi đến thẩm phán trực tuyến yêu thích của bạn, thử thách bản thân. Khi ai đó nhìn vào màn hình của bạn, anh ta sẽ bắt bạn lập trình. ;)


2

Bạn có thể trả lời điều này theo hai cách. Có và không, hoặc nó phụ thuộc. - Tôi có thể mơ hồ hơn ....

Nó phụ thuộc nếu nó được yêu cầu cho họ để làm công việc của họ. Nếu đó là cấp cho họ quyền hạn hành chính trên máy tính của họ. Nếu không thì đừng. Không phải tất cả sự phát triển phần mềm đều yêu cầu một kỹ sư phải có quyền quản trị.

Có và không phụ thuộc vào quan điểm của bạn. Một số kỹ sư xem máy tính của họ là miền của họ và họ là quy tắc của miền. Những người khác không muốn chịu trách nhiệm.

Tôi đã làm việc tại một công ty nơi tôi không có quyền quản trị viên và bất cứ khi nào tôi cần làm điều gì đó đòi hỏi quyền quản trị, tôi phải gọi cho bộ phận trợ giúp và họ cấp cho tôi quyền quản trị tạm thời cho đến khi tôi khởi động lại. Đôi khi điều này là một nỗi đau, nhưng đó là cách tôi đã sống với nó. Tôi cũng đã làm việc ở những nơi mà tôi có toàn quyền quản trị đối với máy tính của mình. Điều này thật tuyệt vời trừ khi tôi cài đặt một số phần mềm đã cài đặt HĐH và phải đưa máy tính của tôi đến bàn trợ giúp và để chúng hình ảnh lại ổ cứng ....

Cá nhân tôi cảm thấy rằng một kỹ sư nên có quyền quản trị viên đối với máy tính của họ, nhưng với sự hiểu biết rằng nếu họ làm hỏng nó thì một hình ảnh đường cơ sở mới có thể được tải lại và họ sẽ mất bất cứ thứ gì được thực hiện kể từ đường cơ sở ban đầu. Tuy nhiên, tôi không tin rằng mọi người trong công ty nên có quyền quản trị viên đối với máy tính của họ. Kế toán, trợ lý hành chính và các bộ phận khác không thực sự cần phải có những quyền đó nên không được cấp.


Tôi đã từng là một nhà thầu cho một công ty, để có được quyền quản trị, tôi đã phải ký một xác nhận rằng nhân viên CNTT sẽ mất không quá mười hoặc mười lăm phút để sửa máy tính của tôi và sau đó sẽ xóa sạch hoàn toàn hình ảnh. Nó có vẻ công bằng với tôi.
David Thornley

Đã đồng ý. Với sức mạnh lớn đến trách nhiệm lớn.
CraigTP

2

ht tp: //msdn.microsoft.com/en-us/l Library / aa302367.aspx

Theo kinh nghiệm của tôi, luôn cần một sự thỏa hiệp giữa chúng tôi (lập trình viên) và họ (bảo mật). Tôi thừa nhận (mặc dù tôi ghét), có công trong bài viết của Microsoft ở trên. Vì tôi đã là một lập trình viên trong nhiều năm, tôi đã trải qua nỗi đau mà tôi chỉ cần cài đặt một trình gỡ lỗi khác, chỉ để làm phiền tôi không thể. Nó buộc tôi phải suy nghĩ sáng tạo trong cách hoàn thành công việc của mình. Sau nhiều năm chiến đấu với đội an ninh của chúng tôi (và một vài cuộc thảo luận), tôi hiểu công việc của họ là phải bảo mật tất cả các lĩnh vực, bao gồm cả máy tính để bàn của tôi. Họ chỉ cho tôi các lỗ hổng hàng ngày xuất hiện, ngay cả trên ứng dụng Quicktime đơn giản nhất. Tôi có thể thấy sự tàn phá của họ mỗi khi tôi muốn cài đặt một tiện ích nhanh hoặc điều chỉnh IIS cục bộ của mình mà tôi có thể gây ra sự cố bảo mật nghiêm trọng. Tôi đã không hoàn toàn hiểu điều này cho đến khi tôi thấy một nhà phát triển khác bị đóng hộp. Anh ta đang cố gắng gỡ lỗi và cuối cùng chỉ tắt Symantec để lấy (và sau đó GIVE) một số virus cho hàng trăm người. Nó là một mớ hỗn độn. Khi nói chuyện với một trong những "sechead" (nhân viên an ninh) về những gì đã xảy ra, tôi có thể thấy anh ấy chỉ muốn nói, "đã nói với bạn như vậy ...".

Tôi đã học được rằng các sechead của chúng tôi (tốt, ít nhất là của tôi) chỉ muốn bảo vệ công ty của chúng tôi. Tin tốt là chúng tôi đã tìm được một sự thỏa hiệp và tôi có thể hoàn thành công việc của mình và các sechead rất tuyệt với mạng an toàn của chúng tôi!

Tín điều


1

Có nếu bạn muốn các pentesters hoặc một số người dùng độc hại có kỹ năng có được chỗ đứng trong việc thỏa hiệp tên miền của bạn.

tức là Thỏa hiệp tài khoản cấp thấp> Tìm nơi quản trị viên -> Mimikatz -> Nâng cao quyền -> Quản trị viên tên miền.

Vì vậy, không, người dùng bình thường không nên là quản trị viên.

Ngoài ra Microsoft đã nói UAC không phải là một ranh giới bảo mật, vì vậy đừng sử dụng nó như vậy. Có nhiều cách bỏ qua thế giới thực khác nhau của UAC.

Nếu họ cần quản trị viên như một phần vai trò công việc của họ thì hãy cung cấp tài khoản người dùng quản trị viên tên miền riêng biệt chỉ được sử dụng để cài đặt phần mềm (chỉ có quyền quản trị viên trên máy của họ), không bao giờ được sử dụng chung hoặc truy cập internet. Điều này cần có chính sách mật khẩu nghiêm ngặt hơn (ví dụ: độ dài tối thiểu 15 ký tự). Chức năng Runas nên được sử dụng cho việc này.

Bất kỳ môi trường nào có tài khoản người dùng bình thường là quản trị viên là một công thức cho thảm họa bảo mật.


0

Wow, câu hỏi này chắc chắn sẽ mở ra một số câu trả lời thú vị. Trả lời tôi trích dẫn oft được sử dụng - 'Nó phụ thuộc' :)

Trong các công ty nhỏ, điều này có thể chỉ đơn giản là vấn đề thực dụng. Các nhà phát triển cũng có khả năng là những người lão luyện nhất về mặt kỹ thuật, do đó, thật hợp lý khi họ quản trị các máy của chính họ.

Cá nhân tôi là một fan hâm mộ của "tài khoản quản trị viên" có thể được sử dụng khi cần thiết - tức là "Chạy như .." (Tôi nhận thấy cách tiếp cận này rất giống với UAC sau này).

Nếu bạn đang phát triển phần mềm máy tính để bàn, thì các nhà phát triển sẽ không làm việc trong giới hạn mà người dùng cuối của họ sẽ trải nghiệm - tức là quyền hạn chế hoặc bị hạn chế. Nếu bạn xây dựng phần mềm theo các quyền hạn chế, rất có thể bạn sẽ gặp phải những vấn đề tương tự mà người dùng mục tiêu của bạn sẽ gặp phải với cùng một bộ quyền.

Phải nói rằng, nếu bạn có một phòng thí nghiệm kiểm tra tốt và / hoặc một nhóm QA đàng hoàng thì đây có thể là một điểm cần thiết - đặc biệt là nếu bạn có một thực hành ALM nửa vời.

Vì vậy, cuối cùng - tôi phát triển mà không có UAC, chủ yếu là vì tôi tin tưởng vào bản thân và kỹ năng của mình. Trong môi trường nhóm, tôi sẽ bỏ phiếu. Trong các tổ chức lớn hơn, bạn có thể không có quyền tự do này .. Quản trị viên doanh nghiệp thường có tiếng nói cuối cùng :)


0

Tại công ty của tôi, các nhà phát triển, kỹ sư và sếp của tôi (chủ sở hữu công ty) có đặc quyền quản trị viên địa phương. Sếp của tôi cũng có đặc quyền quản trị mạng, chỉ trong trường hợp tôi bị xe buýt bướng bỉnh đó (hoặc bỏ). Mọi người khác bị khóa.

Như sysadmin, thiết lập này thỉnh thoảng gây cho tôi một chút đau buồn, đặc biệt là khi phần mềm không được chấp thuận được cài đặt. Tuy nhiên, xuất phát từ nền tảng của nhà phát triển, tôi hiểu rằng người dùng có quyền kiểm soát nhiều hơn đối với môi trường của họ và do đó, sẵn sàng đưa ra những vấn đề hay sự cố có thể xảy ra. Tôi thực hiện sao lưu thường xuyên các máy trạm của họ - chỉ trong trường hợp.

Nhân tiện, tôi đã gặp nhiều vấn đề với ông chủ mày mò mọi thứ hơn bất cứ ai khác. Kiểu như câu hỏi cũ, "Con voi ngồi ở đâu? Bất cứ nơi nào nó muốn!" Nhưng trong một công ty nhỏ nơi anh ấy thực chất là sysadmin "dự phòng", không có nhiều sự lựa chọn.


-1

Nó phụ thuộc vào các kỹ năng của nhà phát triển và liệu họ có phải là nhà tư vấn hay không.

Tôi nghĩ thật hợp lý khi một nhà phát triển dày dạn và đáng tin cậy có quyền làm bất cứ điều gì anh ta muốn với PC của mình miễn là điều đó không gây hại cho năng suất của anh ta.


6
Tại sao bạn lại trói tay một nhà tư vấn mà không phải là một nhân viên bình thường? Cả hai không làm cùng một công việc sao? Bạn có mong đợi ít hơn từ nhà tư vấn mặc dù bạn có khả năng trả nhiều tiền hơn cho họ? Điều này nghe thật ngu ngốc. Hơn nữa, nếu một nhà phát triển không thể giữ cho máy của họ chạy, họ cần một công việc mới
NotMe

-1

Không ai trên Windows XP nên sử dụng tài khoản quản trị viên để sử dụng hàng ngày và trong Vista nếu bạn phải là quản trị viên ít nhất phải bật UAC. Đặc biệt là các nhà phát triển web và các nhà phát triển khác duyệt web bằng Internet Explorer.

Những gì bạn có thể làm là yêu cầu các nhà phát triển sử dụng tài khoản người dùng thông thường của họ, nhưng cung cấp cho họ tài khoản thứ hai là quản trị viên trên PC của họ để họ có thể sử dụng nó khi cần (Run As). Tôi biết họ nói phát triển web, nhưng để phát triển Windows, phần mềm của bạn nên được kiểm tra bằng tài khoản người dùng thông thường, không phải với tư cách quản trị viên.

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.