개발자에게 PC에 대한 관리자 권한이 있어야합니다
개발자가 자신의 PC에 대한 관리자 권한을 가지고 있어야합니까, 아니면 고급 사용자 액세스 권한을 부여해야합니까?
일부 의견 :
- 설치가 필요한 새로운 응용 프로그램을 시험해보고 싶다면 가상 컴퓨터에서 시도한 다음 네트워크 관리자가 설치하도록 할 수 있습니다. 그게 효과가 있다고 생각합니까?
- 관리자 권한이 필요한 개발자가 PC에서 수행해야 할 작업이 있습니까?
우리는 5 명의 개발자로 구성된 팀이며 웹 애플리케이션을 구축합니다.
대답은 '예'입니다. 개발자는 시스템 구성을 사용하여 항목을 테스트하고, 소프트웨어를 설치하고 (아무것도 개발중인 설치 프로세스를 테스트하기 위해) 레지스트리를 찌르고 관리자 권한없이 제대로 작동하지 않는 소프트웨어를 실행해야합니다 (단지 몇 가지 항목을 나열). 관리 작업을 수행해야하는 개발 작업에 필수적인 다른 작업이 많이 있습니다.
개발 직원이 프로덕션 시스템에 대한 루트 액세스 권한을 반드시 가질 필요는 없으며 로컬 PC의 관리자 권한이 프로덕션 시스템의 보안을 크게 손상 시키지는 않습니다. 업무 수행에 필요한 직원을 위해 로컬 PC에 대한 관리자 액세스를 제한하는 합법적 인 운영 이유는 거의 없습니다.
그러나 관리 액세스 권한을 제공하는 가장 중요한 이유는 손상되거나 2 차 개발 환경을 설정하면 개발 직원에게 메시지를 보내기 때문입니다.
'우리는 정당한 이유없이 귀하의 업무 수행 능력을 크게 손상시킬 준비가되어 있기 때문에 귀하의 업무를 소중하게 생각합니다. 실제로, 우리는 우리 자신의 주장을 다루기 위해 아주 기쁘고 사소한 관료주의의 변덕에 빠지거나 단순히 귀찮게 할 수 없기 때문에 매우 기쁩니다. 그게 가장 좋은 경우입니다. 최악의 경우는 우리가 실제로 일을 수행하는 방법과 수행 할 필요가 있거나하지 않아도되는 것을 알려주는 일종의 통제 괴물이라는 것입니다. 당신이받은 것을 처리하고 직업을 갖은 것에 감사하십시오. '
일반적으로 개발 직원을위한 2 차 (기본적으로 결함이있는 작업 환경)를 제공하는 것은 직원을 화나게 한 결과, 유능한 직원을 보유 할 수 없거나 직원의 이직률이 떨어지며 사기가 나쁘고 품질이 좋지 않은 결과를 초래하는 레시피입니다. 특히 관료 주의적 변덕에 대한 패 더닝이 많은 경우에는 그렇게하지 않는 것이 무책임하다.
직원 이직률은 직원 교체 비용 만 발생하지 않습니다. 직원 이직의 가장 심각한 비용은 고집이 많은 사람들이 더 나은 일자리를 얻을 수없는 데드 우드가 될 것입니다. 시간이 지남에 따라 영향을받는 부서의 기능이 저하됩니다. 업종이 충분히 가까워지면 명성을 얻을 수도 있습니다.
한 가지 주목할 점은 관리 권한은 Windows보다 Uniix-oid 또는 메인 프레임 시스템에서 개발하는 데 훨씬 덜 중요하다는 것입니다. 이러한 플랫폼에서 사용자는 시스템 전체 권한 없이도 자신의 도메인에서 훨씬 더 많은 작업을 수행 할 수 있습니다. 개발자는 여전히 루트 또는 sudo 액세스를 원할 것입니다. 그러나이를 사용하지 않으면 발자국이 훨씬 줄어 듭니다. 이 유연성은 컴퓨터 과학 학교에서 유닉스 파생 운영 체제의 지속적인 인기에 대한 중요하지만 덜 알려진 이유입니다.
개발자는 사용중인 머신을 완전히 제어 할 수 있어야합니다. 대부분의 디버깅 도구는 빌드중인 응용 프로그램의 런타임에 연결하기 위해 관리자 권한이 필요합니다.
또한 개발자는 자주 새로운 것을 다운로드하여 시도합니다. 네트워크 관리자가 와서 무언가를 설치 해야하는 등의 추가 단계를 추가하면 개발자를 좌절시키고 네트워크 운영 담당자에게 생명을 위협 할 수 있습니다.
즉, 네트워크가 아니라 THEIR 상자의 관리자 여야합니다.
예, 아니오
예, 시스템 지원을 방해하는 많은 시간을 절약합니다.
아니요, 사용자에게는 보유하지 않으므로 의지하지 마십시오.
우리는 관리자 권한으로 개발하고없이 테스트합니다. 어느 것이 잘 작동합니까?
위에 언급 된 모든 이유로 로컬 관리자 예. 네트워크 관리자 아니요. "그들이 할 수 있기 때문에"네트워크 관리 작업에 빠질 수 없기 때문입니다. 개발자는 개발 중이어야합니다. 네트워크 관리는 완전히 다른 작업입니다.
개발자는 일반적으로 보통 사람이하지 않는 일을해야하므로 일반적으로 관리자 계정이 있어야합니다. 어색한 후프를 뛰어 넘으면 시간이 낭비되고 사기가 줄어 듭니다. 보안 수준이 높은 상황에서는 예외가있을 수 있지만 관리자 계정으로 누군가를 신뢰할 수 없으면 해당 코드를 신뢰할 수 없습니다.
또한 사용자와 동일한 권한을 가진 사용 가능한 계정이 있어야합니다 (사용자 풀의 권한 상태가 다른 경우 둘 이상의 계정). 그렇지 않으면 멋진 것을 개발하고 배포 한 다음 사용자에게 적합하지 않을 수 있습니다.
관리자 계정으로 컴퓨터를 망칠 수있는 방법이 너무 많습니다 (예, 완료했습니다). IT 부서는 개발자의 컴퓨터를 신속하게 수정할 수없는 경우 이미지를 다시 작성한다는 정책이 필요합니다. 계약 한 곳에서 관리자 계정을 얻기 위해 해당 정책의 사본에 서명해야했습니다.
이것은 Windows 고유의 답변입니다. Linux 및 기타 Unix-y 시스템에서 개발자는 사용자 계정만으로 더 자주 접근 할 수 있으며 테스트를 위해 다른 계정이 필요하지 않은 경우가 있습니다 (수행 할 수있는 계정이있는 경우 사용시기를 알고 있음) sudo는 동일하지만 그룹 권한이 동일한 그룹이 필요할 수 있으며 OS에 매우 많은 양의 손상을 줄 수 있으므로 동일한 IT 정책이 필요합니다.
예, Half-Life 1 (및 모든 관련 모드 : 카운터 스트라이크, 패배 일 등)는 Windows NT, 2000, XP 등에서 제대로 작동하려면 관리자 권한이 필요합니다 (적어도 첫 번째 실행에 대해서는 생각합니다). .
그리고 점심 시간에 어떤 종류의 개발자가 카운터 스트라이크를하지 않습니까? (확실히 확실한 것)
기계에 대한 관리자 권한없이 개발해야하는 고통을 견뎌냈지만 내 대답은 그렇습니다.
정답은 개발자에게 2 대의 머신이 있어야한다는 것입니다.
관리자 권한과 충분한 전원, 메모리, 화면 크기 및 이식성 및 ADMIN 권한이 있고 회사 안티 바이러스 소프트웨어가로드되었지만 자동 재설정 정책이 필요한 경우 개발자가 구성 할 수있는 하나의 개발.
회사 부하, 정책, 관리자가 아닌 사용자 권한 등이있는 하나의 회사 하나 ... 개발자는 일부 개발자가 관리자 권한으로 모든 단위 테스트를 수행해야하는 불쾌한 습관을 가지므로 단위 테스트 릴리스 모드 응용 프로그램에이를 사용할 수 있습니다.
물론! 밤에 영화를 다운로드하기 위해 다운로드 관리자를 어떻게 설치합니까?
때때로 개발자는 실제로 아이디어를 테스트하기 위해 시스템에 설치하거나 무언가를 변경해야합니다. 무언가를 변경해야 할 때마다 관리자에게 연락해야 할 경우 불가능합니다.
또한 일부 관리자는 매일 일에 의존하지 않는 작은 일을하기 위해 가능한 모든 것을 조이는 경향이 있다는 개인적인 견해를 가지고 있습니다. 다른 사용자를 화나게? 대답이 없습니다. 그러나 여기서 상식은 보이지 않습니다.
Last time there was a problem with my PC I took an active part in restoring the system, making some suggestions working in the team with the admin, or so i thought... Admin turned to be very angry and accused me of trying to teach him or redefine the rules. I suppose it was just his ego as he was not seen that cool in our room among other colleagues.
If you invert the question I think it becomes easier to answer; should we remove administrator permissions from developers? What is the gain?
But actually, I think the answer depends on your context, your environment. Small startup will have a different answer to ISO-certified government agency.
Yes, but they need to be aware of the limitations that their users will face when running software in a more limited environment. Developers should have easy access to "typical" environments with limited resources and permissions. In the past I have incorporated deploying builds to one of these "typical" systems (often a VM on my own workstation) as part of the build process, so that I could always get a quick feel for how the software worked on an end-user's machine.
Programmers also have a responsibility to know the hard-and-fast rules of writing software for non-admin users. They should know exactly which system resources they are always allowed (or forbidden) to access. They should know the APIs that are used to acquire these resources.
"It works on my machine" is never an excuse!
As a systems admin I'm all for developers having local admin rights on their workstations. When possible, it's not a bad idea to do most things with a standard 'user' level account and then use another 'admin' account to make changes, install apps etc. Often you can sudo or runas to accomplish what you want without even logging out. It's also helpful to remind us of what security hurtles the end-users will have to jump through when releasing to production.
On a side note it's also advisable to have a [clean] system or VM(s) so that you can test things properly and not get into the "it looks/works fine on my system" scenario due to system tweaking.
No Power User
First of all, Power User is basically an administrator - so "limiting" a user to Power User does not provide any increase in security to the system - you might as well be administrator.
Log on interactively as a normal user
Second, of course a developer needs administrative access to their developer machine (and servers and second boxes and so on) but of course noone should interactively log on as administrator during normal development or testing. Use a normal user account for this and most applications.
You seriously do not want to run [insert any browser, plugin, IM, E-mail client and so on] as an administrator.
You don't normally log onto your Linux box as root either, even if you likely have root access when you need it.
Use a separate personal administrator account
Provide the developer with a separate personal administrator account to his/her machine (domain account preferably) that is also a valid administrator on other dev/test servers and boxes that person needs administrative access to.
Utilize "run as" and in Vista+ UAC to prompt or request prompt and enter the administrative credentials for tasks and processes only when needed. PKI with smartcards or similar can greatly reduce the strain in entering credentials often.
Everyone is happy (or? ;)
Then audit access. This way there's traceability, and an easy way to find out who is using the terminal services sessions on a particular dev/test server you have to access right now...
Granted, there's definitely development work that will never require local administrator privileges - like most web development where deployment is tested against a separate server or virtual machine and where cassini or whatever is used for local debugging actually runs well as a normal user.
I work primarily in the *nix world and the standard model there is for developers to work in a normal, non-privileged user account with the ability (via sudo or su) to escalate to admin privileges as/when necessary.
I'm not sure what the equivalent Windows arrangement would be, but this is, in my experience, the ideal setup:
On the one hand, having admin rights available on demand gives the developer full power over his workstation when needed.
On the other, Windows software has a long, long history of assuming that all users have admin rights, to the point that many programs won't run for a non-admin user. Many of Windows' security issues stem directly from this implicit requirement that, in order to be able to reliably use the computer, all users must be admins. This must change and the most effective way to ensure that your software will run for non-admin users is for your developers to be running it themselves as non-admin users.
[apologies english is not my mother tongue, doing my best :)] Well,
Personal experience (I'm a c++/SQL dev):
I used to be admin of my windows machine in my previous job. I also had dbo ( not dba ) rights on databases, including production environment databases. In 2 and a half year with 8 people having these crazy high rights... we never had any trouble. Actually we solved a lot of problems by updating db manually. We could do many things really fast for hot fixes and devs.
Now I changed job. I managed ( crying a lot ) to be admin of my windows machine. But the dev server is a red hat server to which we connect using ssh. Trying to install Qt was a torture, Quota limits, space limits, execution and write rights. We finally gave up and asked the admin to do it for us. 2 weeks later still nothing is installed. I'm getting really fast at newspaper reading and alt+tab hitting.
I asked for admin rights, as only the dev of my soft use this machine.
--> Answer: "If there are processes its for you not to do whatever you want. It has to run fine once in prod".
--> Trying to explain to a non technical manager: "I shall have no admin rights whatsoever in production or UAT environments. But my dev machine is different. If I were to build chairs instead of softwares, would you tell me that I can't put whatever tools I want in my workshop because my workshop needs to look like the place the chair will be used ? I give an executable package to uat. The libs and tools I used to build them are invisible to the end user or to the dude installing the package."
I'm still waiting today. I found a solution, open a dev environement, go to your favorite online judge, challenge yourself. when somebody look at your screen, he'll be seing you programming. ;)
You can answer this in two ways. Yes and no, or it depends. -- Can I be more vague....
It depends if it is required for them to do their job. If it is then grant them administrative powers over their computer. If not then don't. Not all software development requires an engineer to have admin rights.
Yes and no depends on your view. Some engineers view their computer as their domain and they are the rules of their domain. Others don't want the responsibility.
I have worked at one company where I did not have admin rights and whenever I needed to do something that required admin rights I had to call the help desk and they granted me temp admin rights until I rebooted. This was a pain at times, but that was the way it was so I lived with it. I have also worked at places that I have full admin rights to my computer. This was great except for the time I installed some software that hosed the OS and had to take my computer to the help desk and have them re-image the hard drive....
I personally feel that an engineer should have admin rights to their computer, but with the understanding that if they screw it up then a new baseline image can be reloaded and they will lose anything that was done since the original baseline. I don't believe that everyone in a company should have admin rights to their computer however. Accounting, administrative assistants, and other departments don't really have a need to have those rights so they should not be granted.
ht tp://msdn.microsoft.com/en-us/library/aa302367.aspx
In my experience, a compromise between us (coders) and them (security) is always needed. I admit (though I hate to), there is merit in the Microsoft article above. As I have been a programmer for years, I have experienced the pain where I needed to just install a different debugger, just to get annoyed I can't. It forced me to think creatively in how to get my job done. After years of battling our security team (and several discussions), I understand their job of having to secure all areas, including my desktop. They showed me the daily vulnerabilities that come out, even on the simplest Quicktime app. I can see their frutration everytime I want to install a quick utility or tweak my local IIS that I can cause a serious security problem. I didn't fully understand this until I saw another developer get canned. He was trying to debug and ended up shutting off Symantec only to get (and then GIVE) some virus to hundreds of people. It was a mess. In talking to the one of the "secheads" (security guys) about what happened, I could see he wanted to just say, "told you so...".
I have learned that our secheads (well, at least mine) just want to protect our company. The good news is we did find a compromise, and I can get my job done and the secheads are cool with our secure network!
Creed
Yes if you want the pentesters or some skilled malicious users to get a foothold on compromising your domain.
i.e Compromise low level account > Find where admin -> Mimikatz -> Elevate permissions -> Domain admin.
So no, normal users should not be admins.
Also Microsoft have said UAC is not a security boundary, so don't use it as such. There are various real world bypasses of UAC available.
If they need admin as part of their job role then give out separate domain local admin user accounts used for installing software only (with admin permissions on their own machine only), never for general usage or internet access. This should have a more stringent password policy (eg 15 chars minimum length). Runas functionality should be used for this.
Any environment where normal user accounts are admin is a recipe for a security disaster.
Wow, this question is certainly going to open up to some interesting answers. In reply I quote the oft used - 'It Depends' :)
In small companies this might just be simply a matter of being pragmatic. The developers are also likely to be the most technically adept, so it makes sense for them to adminster their own machines.
Personally, I'm a fan of the "admin account" which can be used when necessary - i.e. "Run As.." (I noticed this approach was very similar in principal to UAC later on).
If you are developing desktop software it's not a bad idea for developers to work within the confines that their end user's will experience - i.e. limited or restricted rights. If you build the software under limited rights, it's a good chance that you'll hit the same problems your target users would face given the same set of permissions.
Having said that, if you have a good testing lab and/or a decent QA team this might be a moot point - especially if you have a half decent ALM practice.
So finally - I develop without UAC, mainly because I trust myself and my skills. In a team environment, I'd put it to a vote. In larger organizations you might not have this freedom.. The Enterprise Admins often have the final say :)
At my company, developers, engineers, and my boss (owner of the company) have local admin privilege. My boss also has network admin privilege, just in case I get hit by that wayward bus (or quit). Everyone else gets locked down.
As sysadmin, this setup has caused me a little grief from time to time, especially when unapproved software gets installed. However, coming from a developer background, I understand the need for power users to have more control over their environment and as such, am willing to put up with the occasional quirk or problem that may surface. I do perform routine backups of their workstations -- just in case.
By the way, I've had more problems with the boss tinkering around with things than with anyone else. Kind of like the old question, "Where does an elephant sit? Anywhere he wants!" But in a small firm where he is essentially the "backup" sysadmin, there isn't much choice.
It depends on the developer skills and whether s/he is a consultant or not.
I think it's reasonable that a seasoned and trustworthy developer has the rights to do whatever s/he wants with her/his PC as long as it doesn't harm her/his productivity.
No one on Windows XP should be using an administrator account for day-to-day use, and in Vista if you must be an administrator at least have UAC enabled. Especially web developers and other developers who browse the web with Internet Explorer.
What you can do is have developers use their regular user account, but give them a second account that is an administrator on their PC so they can use it as needed (Run As). I know they said web development, but for Windows development your software should be tested using a regular user account, not as an administrator.
'IT story' 카테고리의 다른 글
| VS2012 솔루션을 VS2010으로 변환 (0) | 2020.07.04 |
|---|---|
| nodejs를 사용하여 이미지를 제공하는 방법 (0) | 2020.07.04 |
| 새로운 활동을 시작할 때 활동 슬라이드 인 애니메이션을 비활성화 하시겠습니까? (0) | 2020.07.04 |
| JavaScript-두 날짜 사이에 분을 가져옵니다 (0) | 2020.07.04 |
| 동일한 TextView에서 문자열의 다른 글꼴 크기 (0) | 2020.07.04 |