개발자 머신을 잠그는 것이 가치보다 더 많은 노력입니까? [닫은]


19

개발자로 일하고 개발 팀의 IT 관리자 / 지원 부서에서 근무하면서 저는 완전히 잠겨있는 것부터 완전히 그렇지 않은 것까지 다양한 유형의 환경을 경험했습니다. 제한된 지원 경험에서 나는 덜 잠긴 기계로 지원하려는 노력이 줄어들 었다고 생각하고 이것이 더 쉽다고 생각했지만 물론 이것은 편견이 될 수 있다고 생각했습니다. IT 지원 관점에서 어떤 견해를 갖고 싶은지 알고 싶습니다. 컴퓨터를 잠그지 않은 개발자를 지원하는 것이 실제로 더 어려운가요?


10
Stack Overflow의 Server Fault 모집단의 대규모 프로그래머 세그먼트를 고려할 때 선택 바이어스로 인해 어려움을 겪고 있습니다. 어떤 개발자가 정말로 '잠금 해주세요!'라고 말할 것입니까?
romandas

답변:


11

개발자 컴퓨터를 잠그지 않는 가장 큰 문제는 개발하는 모든 소프트웨어를 실행하려면 전체 관리자 권한이 필요하다는 것입니다. 개발자 액세스는 실행해야하는 환경과 동일해야합니다. "자체 지원 가능"또는 "자체 설치 가능"해야하는 경우 관리자를 수행 할 때 사용해야하는 Bruce.admin과 같은 다른 관리자 계정을 부여하십시오. 물건,하지만 매일 사용되지 않습니다.

적절한 유닉스 관리자가없는 것처럼 소금도 일상적인 비 관리 작업에 루트 계정을 사용합니다.


14
나는 "필요할 것"을 위반합니다. 개발자가 자연스럽게 잘못된 일을 할 것이라는 확실한 결론처럼 들립니다. 필자는 불필요하게 높은 권한으로 만 실행되는 소프트웨어를 개발하는 것이 바람직하지 않다는 데 동의하지만, IT 부서가 기계 잠금과 같은 가혹한 조치로 특정 개발 관행을 시행하려고 시도하지는 않는다고 생각합니다. IT가 응용 프로그램 요구 사항을 정의하는 프로세스의 이해 당사자이며 사내 응용 프로그램이어야하는 경우 더 낮은 권한으로 실행하기 위해 응용 프로그램을 개발하고 테스트해야합니다.
Chris W. Rea

그러나 별도의 계정이라는 아이디어가 장점이라고 생각합니다. 그러나 나에게 그것을 강요하지 마십시오.
Chris W. Rea

4
Windows에서는 다른 방법으로이 작업을 수행하는 것이 좋습니다. 표준 사용자의 권한으로 동작하는 테스트 계정을 만듭니다. 테스트 사용자 계정으로 머신 (또는 VM)에 로그인하여 애플리케이션을 테스트 할 수 있습니다.
ConcernedOfTunbridgeWells

3
15 년 동안의 기술 테스트 경험을 바탕으로 "필요한"의견을 구성했습니다. 물론 예외가 있지만 Windows의 대부분의 응용 프로그램은 최소한의 권한으로 만 설계된 것은 아니며 개발자가 자연스럽게 잘못된 일을하기 때문이 아니라 실제로 적절한 작업을하기가 어렵 기 때문입니다.
Bruce McLeod

1
수천 개의 다른 앱처럼 사용했지만 실제로는 5 %만이 관리자 권한이 필요했습니다.
Mircea Chirea

55

대부분의 개발자는 기술적으로 정통하며 자신이하는 일을 알고 있습니다. 그들은 종종 많은 전문 앱을 설치해야하며,이를 위해서는 허가를 받아야하고 IT가 다운되도록하고 추가해야합니다. 특히 대기업에서 양쪽 모두에게 매우 실망 스러울 수 있습니다.

기계에 소프트웨어를 설치하는 것과 관련하여 그들이 원하는 것을 할 수있게하는 것이 가장 효과적이라는 것을 알았습니다. 그러나 우리가 지원하지 않는 것에 문제가 생기면 그들 스스로입니다. 대부분의 개발자는 이것에 만족하며 어쨌든 자신의 컴퓨터를 돌보는 것을 선호합니다.

IE와 공개 단어 만 사용하도록 계정에서 누군가를 잠그는 것은 좋지만 4 가지 유형의 브라우저를 설치해야하고 문제를 해결하기 위해 앱을 신속하게 설치 해야하는 개발자는 성 가실 수 있습니다.

내 경험은 기술 지식이 풍부하고 직원을 신뢰하고 설치 대상을 결정할 수 있도록 개발 상점, IT 공급 업체 등이 많은 회사가 훨씬 행복하고 IT를 덜 괴롭히는 것입니다.


10
이 답변에 여러 번 투표 할 수 있다면 그렇게하겠습니다. 저는 개발자이며 110 %에 동의합니다. +1
Chris W. Rea

1
@ cwrea : 10 % 초과가 될 수있는 것은 무엇입니까?
setzamora

3
나는 동의하지만, 정보 보안의 측면에서 매우 엄격한 회사는 응용 프로그램이 "회사 표준"없는 것을 설치하는 것을 허용하지 않습니다
setzamora가

방금 관리자 권한이 없어진 후 30 분마다 지원팀에 전자 메일을 보내거나이 설정을 가져 오거나이 설정 또는 설정을 변경하는 것으로 나타났습니다. 배포 날짜를 확인하는 일반적인 테마는 알림 영역에서 시간을 두 번 클릭하는 것이 었습니다. 내가 지금 "적절한 권한 수준을 갖지 못하고있는 것"에 대한 것…

1
'설치를 제거하면 지원되지 않습니다.'라고 말하는 것이 좋지만 실제로는 xyz가 작동하지 않고 Systems / helpdesk가 도움이되지 않는다고 상사에게 불평하는 개발자로 변합니다. 보스는 동료에게 총을 맞았으며, 다음으로 관리자 / 감독 / VP가 알고있는 것은 걱정하지 않는 누군가의 목을 숨겨주는 것입니다. 이제 Systems / Helpdesk는 개발자 a의 경우 임의의 프로그램 xyz와 개발자 b의 경우 임의의 프로그램 abc를 지원해야합니다. 정말로 필요한 경우 채널을 통해 배치하십시오.
Zypher

14

개발자 컴퓨터를 잠그는 장점에 대한 활발한 토론은 이 Stackoverflow 게시물 을 참조하십시오 . (면책 조항 : 나는 대답을 썼다).

sysadmin 관점에서 프로덕션 시스템에 대한 액세스는 민감하므로 작업을 수행해야하는 사람들 (예 : 응용 프로그램에 대한 3 단계 지원 책임이있는 개발자 포함)에 대한 액세스를 제한해야합니다. 개발 PC 또는 개발 서버에 대한 로컬 관리자 권한은 프로덕션 시스템의 보안을 크게 손상시키지 않습니다.

필요한 경우 머신을 재 구축하는 데 사용할 수있는 이미지를 만듭니다. SQL Server dev 에디션, Visual Studio, Cygwin 및 MikTex와 기타 여러 앱을 수동으로 설치하는 데는 시간이 많이 걸립니다. 머신을 많이 재 이미징해야하는 경우 이러한 큰 앱이 설치된 이미지는 상당히 가치가 있습니다.

개발 관점에서 나는 기계의 대부분의 문제를 해결할 수 있으며 일반적으로 매우 드물게 네트워크 지원 직원의 도움 만 필요하다는 것을 알았습니다. 지나치게 제한적인 환경은 개발자가 완벽하게 수행 할 수있는 작업을 수행하기 위해 가짜 개발 지원 트래픽을 생성하는 경향이 있습니다.

개발자가 많은 관리 작업을 수행해야하는 또 다른 장소는 개발 환경을 호스팅하는 데이터베이스 서버입니다. 대부분의 개발자는 일상적인 DBA 작업을 쉽게 학습 할 수 있으며, 이에 대한 실무 지식을 가져야합니다 (IMHO 원칙). 개발 서버의 지나치게 제한적인 관리자 액세스 정책은 여러 가지 방법으로 시작될 수 있습니다.

스크래치 개발 네트워크는 배치 할 수 있다면 아주 좋은 생각입니다. 필요한 경우 프로덕션 서버에서이를 방화벽으로 만들 수 있습니다.

  • 개발자가 프로덕션 환경의 구조를 쉽게 복제 할 수 있으면 후프를 뛰어 넘지 않고도 통합 테스트를 종합 할 수있는 배포 테스트 문화가 촉진됩니다. 이는 프로덕션 릴리스 및 배포 품질을 향상시키는 경향이 있습니다.

  • 프로덕션 환경을 에뮬레이트 할 수 있으면 프로덕션 배포 및 지원 문제에 대한 인식이 높아집니다. 개발 담당자가 프로덕션에서 응용 프로그램이 어떻게 지원되는지 생각하도록 장려하며,이를 염두에두고 구축 된 아키텍처를 장려 할 것입니다.

  • 이 네트워크에 도메인 컨트롤러가있는 경우 기본 도메인 컨트롤러와 해당 계정을 신뢰하도록 트러스트 관계를 설정할 수 있습니다. 이 트러스트 관계는 상호 관계가 아니어도되므로 프로덕션 네트워크 인프라의 보안을 손상시키지 않습니다. 이를 통해 신뢰할 수없는 개발 네트워크를 만들 수 있지만 개발자는 여전히 Exchange 계정이나 파일 서버와 같은 도메인 인증 리소스에 액세스 할 수 있습니다.

  • 후프를 뛰어 넘지 않고 개발자가 실험을 위해 합리적인 범위의 범위를 갖기를 원합니다. 이 작업의 경로에 정치적 장애물을 두는 것은 정치적으로 편리하지만 장기적인 (그리고 종종 인식되지 않는) 기술적 부채를 발생시키는 고약 솔루션을 장려하는 경향이 있습니다. sysadmin 또는 지원 분석가로서 누가 조각을 집어 야하는지 추측하십시오.

나는 이것이 유닉스 나 리눅스 환경에서 훨씬 덜 문제가 될 것이라고 덧붙일 것이다. 사용자는 자신의 환경을 사용자 정의 할 수 있습니다 .profile. 자신의 /home/bloggsj/bin디렉토리 아래에서 원하는 것을 컴파일하고 설치할 수 있습니다 . '로컬 관리자 권한'은 Unix에서 루트 액세스가 필요한 몇 가지 사항이 있지만 대부분 Windows 문제입니다.


마지막 글 머리 기호에 댓글을 달고 싶습니다. 보안 방법의 원래 의도가 무엇임을 명심하십시오 - 당신은 "정치적 장애물"언급 하지만, 정치. 모든 조직은 결국 서한을 따르지만 규칙의 의도를 따르지 않는 사람들을 얻거나 더 나쁘게 한 번 고귀한 정책을 feifdoms으로 왜곡하기 때문에 나중에 다른 것으로 변형 될 수 있습니다. 그러나 좋은 보안과 좋은 정치는 서로 밀접한 관련이 있습니다. 하지만 모든 사람의 성실한 노력이 필요합니다.
quux 2016 년

일반적으로 합리적으로 관리되는 정책은 이러한 유형의 정치적 장애물을 생성하지 않거나 적어도 극복 할 수없는 수준으로 만들지 않습니다. 그러나 IT 정책은 인시던트별로 개발되는 경향이 있으며 항상 '합리적인'것은 아닙니다.
ConcernedOfTunbridgeWells

8

내가 본 것 중 가장 현명한 옵션은 (양쪽에 있지만 여전히), 간단하게 잠금 해제되고 지원되지 않는 것입니다. 그들에게 자유를주고, 그들이 망칠 경우, 그들이 얻을 수있는 것은 표준 이미지로 회복하는 것입니다. 그러한 상황에서 나는 어떤 형태의 "신뢰할 수없는"네트워크에 배치하는 것이 좋은 계획이라고 생각합니다.

잠금이 아닌 개발자 데스크톱의 경우 : 모든 잠금이 생산성을 저해 할뿐 아니라, 합리적으로 숙련 된 개발자가 쉽게 구멍을 찾을 수 있다고 확신합니다.


2
약 20 분 동안 지원을 받고 새로운 이미지를 제공합니다. 우리에게 잘 작동합니다.
Preet Sangha

6

대답은 실제로 : 간단한 예 또는 대답이 없습니다. 그러나 보안은 최소한 다른 사용자만큼이나 개발자 사용자에게 중요합니다.

한편으로, 개발자는 기술적으로 더 정통한 경향이 있습니다. 다른 한편으로, 그들의 업무는 종종 스트레스가 많은 직업이며 그들의 시스템은 안전한 환경으로 자신의 시스템을 유지하는 데 필요한 추가 관리보다 우선 순위를 갖습니다. 이것은 개발자에 대한 비판이 아닙니다. 그들의 일상 업무를 철저히 고려합니다.

개발자에게 시스템에 대한 완벽한 액세스 권한을 부여하려는 경우 다음 추가 조치를 고려해야합니다.

  • 일반적인 non-dev 사용을 위해 일반 사용자 시스템이 잠긴만큼 다른 시스템을 제공하십시오.
    • 전체 액세스 dev 시스템은 dev 자원에만 액세스 할 수있는 특수 VLAN에 배치됩니다.
  • 감염된 시스템이 코드베이스를 위험에 빠뜨리지 못하는 것이 무엇인지 물어보십시오. 백도어 기계가 악의적 인 해커의 손에 악성 코드를 체크인하거나 코드베이스를 제거 할 수 있습니까? 이 위험을 완화하기 위해 적절한 조치를 취하십시오.
  • 마찬가지로, 개발자가 액세스 할 수있는 시스템에 보유 된 비즈니스 데이터를 보호하는 것이 있는지 물어보십시오.
  • 개발 시스템의 소프트웨어 인벤토리 및 보안 감사를 정기적으로 수행하십시오.
    • 그들이 무엇을 실행 중인지 파악하고이 정보를 사용하여 개발자 시스템 재배치 이미지를 빌드하십시오.
    • 조만간 당신은 부주의하게되고 명백히 위험하거나 완전히 업무와 관련이없는 것을 설치하는 개발자를 갖게 될 것입니다. 이러한 상황이 발생하면 경고를 빠르게 보내면 개발자 커뮤니티에 예, 누군가보고 있음을 알리고 합리적인 표준을 준수해야 할 책임이 있음을 알려줍니다.
  • 정기적 인 맬웨어 검사를 수행하고 있습니까? 경우에 따라 개발자는 온 액세스 AV 시스템 (항상 켜져 있고 모든 파일 액세스에서 항상 검색되는 AV 시스템)이 부과하는 성능 세에 대해 올바르게 불만을 제기 할 수 있습니다. 야간 검색 전략으로 이동하거나 온 액세스 검색에 대한 파일 / 폴더 제외를 만드는 것이 좋습니다. 제외 된 파일은 다른 방법으로 스캔해야합니다.
    • 관리자 지원 개발자가 모든 AV 스캔을 끌 수 있습니까? 이것을 어떻게 감지하고 교정하겠습니까?

dev 시스템을 잠 그려면 다음을 고려해야합니다.

  • 지원 요청을 신속하게 처리 할 수있는 지원 역량이 있습니까? 개발자의 평균 지불 속도를 고려하여 더 빠른 응답 시간 SLA를받을 자격이 있는지 묻습니다. 연간 60 만 달러의 지원 요청을 처리하는 동안 1 억 2 천만 달러 규모의 프로젝트 (수백만 달러 프로젝트의 핵심)를 대기시키는 것은 합리적이지 않습니다.
  • 개발자에게 어떤 지원 요청을하고 서비스를 제공하지 않을 것인지에 대한 명확하고 명확한 정책이 있습니까? 그들이 지원이 임의적이라는 느낌을 받기 시작 하면 결국 고통을 느낄 것입니다.

어느 쪽이든 개발자는 특별한 경우이며 어떤 종류의 추가 지원이 필요하다는 것을 인정해야합니다. 예산을 책정하지 않으면 지금 당장 문제가 발생할 수 있습니다.

부수적으로, 나는 sysadmins와 매우 비슷한 논쟁이 일어나는 것을 보았습니다. 적어도 두 가지 다른 작업에서 sysadmins는 스스로 시스템을 잠 그거나 두 번의 로그인 (루트 / 관리자 권한이있는 하나,없는 사람)이 있어야한다고 제안 할 때 매우 신중하게 주장하는 것을 보았습니다. 많은 시스템 관리자는 어떤 식 으로든 고정되어서는 안되며 그러한 조치에 강력하게 반대해야한다고 생각했습니다. 조만간 일부 폐쇄 방지 관리자는 보안 사고가 발생하며이 예는 우리 모두에게 교육적 영향을 미칩니다.

나는 항상 관리자 권한으로 실행 한 sysadmins 중 한 사람이었습니다. 이중 계정으로 변경하고 필요할 때만 높이면 처음 몇 개월 동안 매우 실망 스러웠습니다. 그러나 클라우드의 은빛 안감은 내가 관리하는 시스템의 보안에 대해 더 많이 배웠다는 것입니다. 일반 계정이 사용자에게 부여 한 것과 동일한 제한 사항에 따라 살았을 때입니다. 더 나은 관리자가되었습니다! 개발자도 마찬가지라고 생각합니다. 그리고 운 좋게도 Windows 세계에는 이제 UAC가있어 제한된 사용자로 쉽게 실행하고 필요할 때만 권한을 상승시킬 수 있습니다.

개인적으로 나는 누군가가 어떤 형태의 보안 관행보다 높아야한다고 생각하지 않습니다. 모든 사람 (sysadmins, devs, 상위 관리자 포함)은 충분한 보안 절차와 감독을 받아야만합니다. 달리 말하면 회사 시스템과 데이터는 보호하려는 노력이 가치가 없다고 말하는 것입니다.

다른 방법으로 봅시다. 루트킷 이 Mark Russinovich를 데려 갈 수 있다면 누구나 할 수 있습니다!


3

개발자가 몇 명인 경우 개발 서버를 제공하는 방법은 가능하지만 전체 개발자 층이있는 경우 관리자 권한을 부여하는 것에 크게 반대합니다.

문제는 개발자가 작업을 수행하는 전체 층으로 이어질 수 있다는 것입니다. 각 개발자는 대개 보안에 관심이 없으며 앱이 작동하기를 원합니다. 그런 다음 "개발 단계를 완료했습니다. 개발 환경을 테스트, 사전 제작 및 제작에 복제하십시오"라는 요청이 표시됩니다.

또한 무작위 정크 (잘못된 패키지 소프트웨어)를 설치하는 습관을 들이고 다른 계층의 서버 수십 대에 설치하도록 위임합니다.

정책을 매우 간단하게 만듭니다.

  • 개발자는 개발 환경에 대한 루트 액세스 권한을 얻지 못합니다.
  • 개발자는 사전 개발 VMware 서버에 대한 루트 액세스 권한을 갖지만 지원은 없습니다.
  • 개발자는 앱이 실행될 OS 배포에 속하는 RPM 패키지 또는 FHS 및 LSB를 준수하는 RPM 패키지를 제공해야합니다.
  • 어떤 환경에서도 응용 프로그램을 루트로 실행할 수 없습니다
  • 응용 프로그램 사용자 su또는 sudo응용 프로그램 사용자에게 액세스 권한이 없습니다 -쉘 액세스 권한이 없도록 잠겨 있습니다. (회계 / 감사를위한 것입니다).
  • 권한있는 액세스 권한으로 실행해야하는 명령은 명시 적으로 요청하고 승인해야 sudoers합니다. 이때 명령이 파일에 추가 됩니다.
    • 이 명령 / 스크립트 중 어느 것도 쓸 수 없습니다.
    • 이 명령에 의한 스크립트는 (직접 또는 간접적으로) 참조 할 수 없습니다.

위의 것들은 무엇보다도 프로젝트를 테스트 서버 이상으로 옮길 때 허용되는 것과 그렇지 않을 것에 대해 생각하게합니다.


2

개발자의 컴퓨터를 잠 그려면 가치보다 더 많은 노력이 필요합니다. 관리 권한 없이는 아무 것도 할 수 없으므로 생산성이 심각하게 저하됩니다. 물론, 결국 시스템이 엉망이 되겠지만, IT 부서가 개발에 사용되는 모든 타사 도구를 지원하지 않습니까?

Vincent De Baere가 제안했듯이 최상의 조치는 이미지에서 시스템을 복원하는 것입니다. 물론 그 후 환경을 복원해야하지만 IT의 문제는 아닙니다. N 번 발생하면 해당 사람을 일종의 "블랙리스트"에 올릴 수 있으며, 예를 들어 그의 관리 권한을 잠시 동안 중단 할 수 있습니다.

어느 쪽이든, 환경은 감염된 (또는 엉망인) 컴퓨터가 다른 컴퓨터에 전혀 영향을 미치지 않거나 스팸이나 무언가를 보내지 않는 방식으로 설정되어야합니다. 나는 단지 명백한 것을 말하고 있습니다. 죄송합니다).


1

글쎄, 그것은 당신이 어떤 환경에서 실행하고 있는지에 달려있다. 그러나 Windows 환경을 가정 할 때, 개발 소프트웨어 중 일부는 작업 권한을 높여야하기 때문에 일반적으로 가치보다 문제가 많습니다. 예를 들어 Visual Studio에는 관리자 권한이 필요한 것으로 알려져 있습니다. 따라서 누군가 작업의 필수 부분에 대해 농구 대를 뛰어 넘을 때의 이점을 보지 못합니다.

그러나 회사가 최선의 선택을해야 할 경우 모든 개발자에게 시스템에 가상 머신을 제공하여 미쳐 버릴 수 있습니다. 일부는 그렇게 마음에 들지 않을 수 있지만 둘 다의 장점을 모두 제공 할 수 있습니다. 세계 (예 : 제한적인 일반 데스크탑 및 완전히 사용자 정의 가능한 환경).

업데이트 -Windows 측면에서 약간 더 주목할 가치가 있습니다. 관리자 권한이 필요한 Visual Studio는 약간 오래되었으며 이제 필요한 권한을 설정하는 명확한 방법이 있습니다 (PDF 파일). 그러나 이것이 내가 생각하는 대부분의 개발자가 Visual Studio 이외의 추가 도구를 사용하고 권한 측면에서 필요한 모든 것을 예측하기 어려울 것이라는 점에서 이것이 내 옵션을 변경한다고 생각하지 않습니다.


MS는 VS2005를 관리자 권한으로 실행하는 것이 좋습니다. 그러나 MS의 최고 소프트웨어 보안 담당자 중 하나 인 Michael Howard는 99 %의 시간이 비 관리자처럼 잘 작동한다고 말합니다. blogs.msdn.com/michael_howard/archive/2007/01/04/… ... 보안이 중요한 경우 관리자가 아닌 사람이 실행 해 볼 수 있습니다. 즐거운 놀라움이 당신을 기다립니다!
quux 2016 년

1

제한된 데스크톱 위에서 가상 컴퓨터를 사용한다는 개념에 동의합니다.

달리 필요한 경우가 아니라면 최고의 설정은 무료 가상 머신이있는 제한된 Linux 데스크톱입니다. 리눅스는 나를 위해 오버 헤드를 줄이며, vm은 원하는 OS뿐만 아니라 스냅 샷이나 백업으로 복원 할 수 있으며 일반적으로 다양한 설정이 필요하지 않은 경우 세상이 조금 더 밝아 보입니다. 지원하다.


+1 .. VM이 왜 그렇게 활용되지 않는지 모르겠습니다. 언급 한 목적뿐만 아니라 VM을 사용하면 소프트웨어 배포가 훨씬 쉬워집니다.

1

나는 (개발자로서) 내 기계를 완전히 제어하는 ​​것을 선호합니다. 필요할 때 관리자 권한으로 실행

컴퓨터에 대한 모든 액세스 권한을 갖기 전에 개발자를위한 특별 교육을 제공 할 수 있습니다. 몇 가지 규칙을 설정하면 매번 감사를 통해 모범 사례를 따르는 지 확인할 수 있습니다.

대부분 IT 관리자 / IT 지원보기, 보안 관련 항목 및 높은 권한으로 개발하지 않는 이유에서 IT 인프라에 대해 더 많이 알아야합니다. (그리고 당신이하지 않도록 확인하는 방법 ...)

" 컴퓨터에 대해 알아야 할 모든 것을 알고 있다고 맹목적으로 말하지 마라";-)

네트워킹, 도메인 및 계정 관련 도구, 비 개발 도구의 소프트웨어 설치 등을 통해 계속 지원해야합니다.


한 가지 더 : 적절한 AV가 설치되어 있는지 확인하십시오. 필요한 경우 강제로 ... ;-)
Arjan Einbu

1

내 경험은 잠겨있는 기계 만 필요한 사람들과 관리자 액세스가 필요한 다른 (개발자, 과학자) 사이에 균등하게 분산 된 사용자 집단에 관한 것입니다. 그들은 고급 소프트웨어를 사용하는 사람들이 많은 소프트웨어를 사내에서 사용하지는 않았지만 관리자가 필요로했던 많은 소프트웨어를 사용했으며, 작업을 수행하려면 많은 패키지를 사용해야했기 때문에 사람들이 할 수 있도록하는 것이 가장 합리적이었습니다. 그것 자체.

우리는 다음과 같은 프로세스로 끝났습니다.

  • 표준 이미지에는 Windows, Office, 바이러스 백신, Acrobat, 몇 가지 유틸리티와 같은 기본 도구가 있습니다.
  • 우리는 많은 네트워크 디스크 공간을 제공했습니다. 모든 것이 네트워크에 저장 될 수있을 정도로 충분했습니다. 유일한 예외는 로컬로 유지해야하는 처리 중 비디오 파일이었습니다.
  • 직원 (감독자와상의)은 IT 부서가 PC를 유지 관리하고 모든 설치 및 구성을 수행하거나 관리자가 직접 액세스 할 수있는 두 가지 선택 사항을 가졌습니다. 두 경우 모두 모든 데이터가 네트워크에 백업되었습니다.
  • IT가 시스템을 유지 관리하고 사망 한 경우, 설치에 필요한 추가 소프트웨어를 추가하는 등 시스템을 원래 상태로 되돌 렸습니다.
  • 관리자 액세스 권한이 있고 시스템이 종료 된 경우 수정하고 수정하려고 시도했지만 표준 이미지로 다시 가져 와서 거기서 가져와야했습니다. 로컬 데이터가있는 경우 먼저 데이터를 가져 오려고하지만 SLA는 가능한 빨리 표준 PC를 작동시키는 것이 었습니다.
  • 안티 바이러스 및 안티 멀웨어를 업데이트 된 상태로 유지하려면 Windows 업데이트가 작동하는지 확인하는 방법을 관리자 액세스 권한이있는 사람이 필요했습니다.

우리는 관리자 액세스 권한이있는 모든 사람을 "신뢰할 수없는"vlan에 배치하고 싶었을 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.