개발자로 일하고 개발 팀의 IT 관리자 / 지원 부서에서 근무하면서 저는 완전히 잠겨있는 것부터 완전히 그렇지 않은 것까지 다양한 유형의 환경을 경험했습니다. 제한된 지원 경험에서 나는 덜 잠긴 기계로 지원하려는 노력이 줄어들 었다고 생각하고 이것이 더 쉽다고 생각했지만 물론 이것은 편견이 될 수 있다고 생각했습니다. IT 지원 관점에서 어떤 견해를 갖고 싶은지 알고 싶습니다. 컴퓨터를 잠그지 않은 개발자를 지원하는 것이 실제로 더 어려운가요?
답변
개발자 컴퓨터를 잠그지 않는 가장 큰 문제는 개발하는 모든 소프트웨어를 실행하려면 전체 관리자 권한이 필요하다는 것입니다. 개발자 액세스는 실행해야하는 환경과 동일해야합니다. “자체 지원 가능”또는 “자체 설치 가능”해야하는 경우 관리자를 수행 할 때 사용해야하는 Bruce.admin과 같은 다른 관리자 계정을 부여하십시오. 물건,하지만 매일 사용되지 않습니다.
적절한 유닉스 관리자가없는 것처럼 소금도 일상적인 비 관리 작업에 루트 계정을 사용합니다.
답변
대부분의 개발자는 기술적으로 정통하며 자신이하는 일을 알고 있습니다. 그들은 종종 많은 전문 앱을 설치해야하며,이를 위해서는 허가를 받아야하고 IT가 다운되도록하고 추가해야합니다. 특히 대기업에서 양쪽 모두에게 매우 실망 스러울 수 있습니다.
기계에 소프트웨어를 설치하는 것과 관련하여 그들이 원하는 것을 할 수있게하는 것이 가장 효과적이라는 것을 알았습니다. 그러나 우리가 지원하지 않는 것에 문제가 생기면 그들 스스로입니다. 대부분의 개발자는 이것에 만족하며 어쨌든 자신의 컴퓨터를 돌보는 것을 선호합니다.
IE와 공개 단어 만 사용하도록 계정에서 누군가를 잠그는 것은 좋지만 4 가지 유형의 브라우저를 설치해야하고 문제를 해결하기 위해 앱을 신속하게 설치 해야하는 개발자는 성 가실 수 있습니다.
내 경험은 기술 지식이 풍부하고 직원을 신뢰하고 설치 대상을 결정할 수 있도록 개발 상점, IT 공급 업체 등이 많은 회사가 훨씬 행복하고 IT를 덜 괴롭히는 것입니다.
답변
개발자 컴퓨터를 잠그는 장점에 대한 활발한 토론은 이 Stackoverflow 게시물 을 참조하십시오 . (면책 조항 : 나는 대답을 썼다).
sysadmin 관점에서 프로덕션 시스템에 대한 액세스는 민감하므로 작업을 수행해야하는 사람들 (예 : 응용 프로그램에 대한 3 단계 지원 책임이있는 개발자 포함)에 대한 액세스를 제한해야합니다. 개발 PC 또는 개발 서버에 대한 로컬 관리자 권한은 프로덕션 시스템의 보안을 크게 손상시키지 않습니다.
필요한 경우 머신을 재 구축하는 데 사용할 수있는 이미지를 만듭니다. SQL Server dev 에디션, Visual Studio, Cygwin 및 MikTex와 기타 여러 앱을 수동으로 설치하는 데는 시간이 많이 걸립니다. 머신을 많이 재 이미징해야하는 경우 이러한 큰 앱이 설치된 이미지는 상당히 가치가 있습니다.
개발 관점에서 나는 기계의 대부분의 문제를 해결할 수 있으며 일반적으로 매우 드물게 네트워크 지원 직원의 도움 만 필요하다는 것을 알았습니다. 지나치게 제한적인 환경은 개발자가 완벽하게 수행 할 수있는 작업을 수행하기 위해 가짜 개발 지원 트래픽을 생성하는 경향이 있습니다.
개발자가 많은 관리 작업을 수행해야하는 또 다른 장소는 개발 환경을 호스팅하는 데이터베이스 서버입니다. 대부분의 개발자는 일상적인 DBA 작업을 쉽게 학습 할 수 있으며, 이에 대한 실무 지식을 가져야합니다 (IMHO 원칙). 개발 서버의 지나치게 제한적인 관리자 액세스 정책은 여러 가지 방법으로 시작될 수 있습니다.
스크래치 개발 네트워크는 배치 할 수 있다면 아주 좋은 생각입니다. 필요한 경우 프로덕션 서버에서이를 방화벽으로 만들 수 있습니다.
-
개발자가 프로덕션 환경의 구조를 쉽게 복제 할 수 있으면 후프를 뛰어 넘지 않고도 통합 테스트를 종합 할 수있는 배포 테스트 문화가 촉진됩니다. 이는 프로덕션 릴리스 및 배포 품질을 향상시키는 경향이 있습니다.
-
프로덕션 환경을 에뮬레이트 할 수 있으면 프로덕션 배포 및 지원 문제에 대한 인식이 높아집니다. 개발 담당자가 프로덕션에서 응용 프로그램이 어떻게 지원되는지 생각하도록 장려하며,이를 염두에두고 구축 된 아키텍처를 장려 할 것입니다.
-
이 네트워크에 도메인 컨트롤러가있는 경우 기본 도메인 컨트롤러와 해당 계정을 신뢰하도록 트러스트 관계를 설정할 수 있습니다. 이 트러스트 관계는 상호 관계가 아니어도되므로 프로덕션 네트워크 인프라의 보안을 손상시키지 않습니다. 이를 통해 신뢰할 수없는 개발 네트워크를 만들 수 있지만 개발자는 여전히 Exchange 계정이나 파일 서버와 같은 도메인 인증 리소스에 액세스 할 수 있습니다.
-
후프를 뛰어 넘지 않고 개발자가 실험을 위해 합리적인 범위의 범위를 갖기를 원합니다. 이 작업의 경로에 정치적 장애물을 두는 것은 정치적으로 편리하지만 장기적인 (그리고 종종 인식되지 않는) 기술적 부채를 발생시키는 고약 솔루션을 장려하는 경향이 있습니다. sysadmin 또는 지원 분석가로서 누가 조각을 집어 야하는지 추측하십시오.
나는 이것이 유닉스 나 리눅스 환경에서 훨씬 덜 문제가 될 것이라고 덧붙일 것이다. 사용자는 자신의 환경을 사용자 정의 할 수 있습니다 .profile. 자신의 /home/bloggsj/bin디렉토리 아래에서 원하는 것을 컴파일하고 설치할 수 있습니다 . ‘로컬 관리자 권한’은 Unix에서 루트 액세스가 필요한 몇 가지 사항이 있지만 대부분 Windows 문제입니다.
답변
내가 본 것 중 가장 현명한 옵션은 (양쪽에 있지만 여전히), 간단하게 잠금 해제되고 지원되지 않는 것입니다. 그들에게 자유를주고, 그들이 망칠 경우, 그들이 얻을 수있는 것은 표준 이미지로 회복하는 것입니다. 그러한 상황에서 나는 어떤 형태의 “신뢰할 수없는”네트워크에 배치하는 것이 좋은 계획이라고 생각합니다.
잠금이 아닌 개발자 데스크톱의 경우 : 모든 잠금이 생산성을 저해 할뿐 아니라, 합리적으로 숙련 된 개발자가 쉽게 구멍을 찾을 수 있다고 확신합니다.
답변
대답은 실제로 : 간단한 예 또는 대답이 없습니다. 그러나 보안은 최소한 다른 사용자만큼이나 개발자 사용자에게 중요합니다.
한편으로, 개발자는 기술적으로 더 정통한 경향이 있습니다. 다른 한편으로, 그들의 업무는 종종 스트레스가 많은 직업이며 그들의 시스템은 안전한 환경으로 자신의 시스템을 유지하는 데 필요한 추가 관리보다 우선 순위를 갖습니다. 이것은 개발자에 대한 비판이 아닙니다. 그들의 일상 업무를 철저히 고려합니다.
개발자에게 시스템에 대한 완벽한 액세스 권한을 부여하려는 경우 다음 추가 조치를 고려해야합니다.
- 일반적인 non-dev 사용을 위해 일반 사용자 시스템이 잠긴만큼 다른 시스템을 제공하십시오.
- 전체 액세스 dev 시스템은 dev 자원에만 액세스 할 수있는 특수 VLAN에 배치됩니다.
- 감염된 시스템이 코드베이스를 위험에 빠뜨리지 못하는 것이 무엇인지 물어보십시오. 백도어 기계가 악의적 인 해커의 손에 악성 코드를 체크인하거나 코드베이스를 제거 할 수 있습니까? 이 위험을 완화하기 위해 적절한 조치를 취하십시오.
- 마찬가지로, 개발자가 액세스 할 수있는 시스템에 보유 된 비즈니스 데이터를 보호하는 것이 있는지 물어보십시오.
- 개발 시스템의 소프트웨어 인벤토리 및 보안 감사를 정기적으로 수행하십시오.
- 그들이 무엇을 실행 중인지 파악하고이 정보를 사용하여 개발자 시스템 재배치 이미지를 빌드하십시오.
- 조만간 당신은 부주의하게되고 명백히 위험하거나 완전히 업무와 관련이없는 것을 설치하는 개발자를 갖게 될 것입니다. 이러한 상황이 발생하면 경고를 빠르게 보내면 개발자 커뮤니티에 예, 누군가보고 있음을 알리고 합리적인 표준을 준수해야 할 책임이 있음을 알려줍니다.
- 정기적 인 맬웨어 검사를 수행하고 있습니까? 경우에 따라 개발자는 온 액세스 AV 시스템 (항상 켜져 있고 모든 파일 액세스에서 항상 검색되는 AV 시스템)이 부과하는 성능 세에 대해 올바르게 불만을 제기 할 수 있습니다. 야간 검색 전략으로 이동하거나 온 액세스 검색에 대한 파일 / 폴더 제외를 만드는 것이 좋습니다. 제외 된 파일은 다른 방법으로 스캔해야합니다.
- 관리자 지원 개발자가 모든 AV 스캔을 끌 수 있습니까? 이것을 어떻게 감지하고 교정하겠습니까?
dev 시스템을 잠 그려면 다음을 고려해야합니다.
- 지원 요청을 신속하게 처리 할 수있는 지원 역량이 있습니까? 개발자의 평균 지불 속도를 고려하여 더 빠른 응답 시간 SLA를받을 자격이 있는지 묻습니다. 연간 60 만 달러의 지원 요청을 처리하는 동안 1 억 2 천만 달러 규모의 프로젝트 (수백만 달러 프로젝트의 핵심)를 대기시키는 것은 합리적이지 않습니다.
- 개발자에게 어떤 지원 요청을하고 서비스를 제공하지 않을 것인지에 대한 명확하고 명확한 정책이 있습니까? 그들이 지원이 임의적이라는 느낌을 받기 시작 하면 결국 고통을 느낄 것입니다.
어느 쪽이든 개발자는 특별한 경우이며 어떤 종류의 추가 지원이 필요하다는 것을 인정해야합니다. 예산을 책정하지 않으면 지금 당장 문제가 발생할 수 있습니다.
부수적으로, 나는 sysadmins와 매우 비슷한 논쟁이 일어나는 것을 보았습니다. 적어도 두 가지 다른 작업에서 sysadmins는 스스로 시스템을 잠 그거나 두 번의 로그인 (루트 / 관리자 권한이있는 하나,없는 사람)이 있어야한다고 제안 할 때 매우 신중하게 주장하는 것을 보았습니다. 많은 시스템 관리자는 어떤 식 으로든 고정되어서는 안되며 그러한 조치에 강력하게 반대해야한다고 생각했습니다. 조만간 일부 폐쇄 방지 관리자는 보안 사고가 발생하며이 예는 우리 모두에게 교육적 영향을 미칩니다.
나는 항상 관리자 권한으로 실행 한 sysadmins 중 한 사람이었습니다. 이중 계정으로 변경하고 필요할 때만 높이면 처음 몇 개월 동안 매우 실망 스러웠습니다. 그러나 클라우드의 은빛 안감은 내가 관리하는 시스템의 보안에 대해 더 많이 배웠다는 것입니다. 일반 계정이 사용자에게 부여 한 것과 동일한 제한 사항에 따라 살았을 때입니다. 더 나은 관리자가되었습니다! 개발자도 마찬가지라고 생각합니다. 그리고 운 좋게도 Windows 세계에는 이제 UAC가있어 제한된 사용자로 쉽게 실행하고 필요할 때만 권한을 상승시킬 수 있습니다.
개인적으로 나는 누군가가 어떤 형태의 보안 관행보다 높아야한다고 생각하지 않습니다. 모든 사람 (sysadmins, devs, 상위 관리자 포함)은 충분한 보안 절차와 감독을 받아야만합니다. 달리 말하면 회사 시스템과 데이터는 보호하려는 노력이 가치가 없다고 말하는 것입니다.
다른 방법으로 봅시다. 루트킷 이 Mark Russinovich를 데려 갈 수 있다면 누구나 할 수 있습니다!
답변
개발자가 몇 명인 경우 개발 서버를 제공하는 방법은 가능하지만 전체 개발자 층이있는 경우 관리자 권한을 부여하는 것에 크게 반대합니다.
문제는 개발자가 작업을 수행하는 전체 층으로 이어질 수 있다는 것입니다. 각 개발자는 대개 보안에 관심이 없으며 앱이 작동하기를 원합니다. 그런 다음 “개발 단계를 완료했습니다. 개발 환경을 테스트, 사전 제작 및 제작에 복제하십시오”라는 요청이 표시됩니다.
또한 무작위 정크 (잘못된 패키지 소프트웨어)를 설치하는 습관을 들이고 다른 계층의 서버 수십 대에 설치하도록 위임합니다.
정책을 매우 간단하게 만듭니다.
- 개발자는 개발 환경에 대한 루트 액세스 권한을 얻지 못합니다.
- 개발자는 사전 개발 VMware 서버에 대한 루트 액세스 권한을 갖지만 지원은 없습니다.
- 개발자는 앱이 실행될 OS 배포에 속하는 RPM 패키지 또는 FHS 및 LSB를 준수하는 RPM 패키지를 제공해야합니다.
- 어떤 환경에서도 응용 프로그램을 루트로 실행할 수 없습니다
- 응용 프로그램 사용자
su또는sudo응용 프로그램 사용자에게 액세스 권한이 없습니다 -쉘 액세스 권한이 없도록 잠겨 있습니다. (회계 / 감사를위한 것입니다). - 권한있는 액세스 권한으로 실행해야하는 명령은 명시 적으로 요청하고 승인해야
sudoers합니다. 이때 명령이 파일에 추가 됩니다.- 이 명령 / 스크립트 중 어느 것도 쓸 수 없습니다.
- 이 명령에 의한 스크립트는 (직접 또는 간접적으로) 참조 할 수 없습니다.
위의 것들은 무엇보다도 프로젝트를 테스트 서버 이상으로 옮길 때 허용되는 것과 그렇지 않을 것에 대해 생각하게합니다.
답변
개발자의 컴퓨터를 잠 그려면 가치보다 더 많은 노력이 필요합니다. 관리 권한 없이는 아무 것도 할 수 없으므로 생산성이 심각하게 저하됩니다. 물론, 결국 시스템이 엉망이 되겠지만, IT 부서가 개발에 사용되는 모든 타사 도구를 지원하지 않습니까?
Vincent De Baere가 제안했듯이 최상의 조치는 이미지에서 시스템을 복원하는 것입니다. 물론 그 후 환경을 복원해야하지만 IT의 문제는 아닙니다. N 번 발생하면 해당 사람을 일종의 “블랙리스트”에 올릴 수 있으며, 예를 들어 그의 관리 권한을 잠시 동안 중단 할 수 있습니다.
어느 쪽이든, 환경은 감염된 (또는 엉망인) 컴퓨터가 다른 컴퓨터에 전혀 영향을 미치지 않거나 스팸이나 무언가를 보내지 않는 방식으로 설정되어야합니다. 나는 단지 명백한 것을 말하고 있습니다. 죄송합니다).