개발자의 랩톱에 중요한 데이터베이스를 저장하기위한 좋은 보안 방법은 무엇입니까?

33

우리는 몇 가지 주어진 것들이 있습니다 :

개발자는 머신에 프로덕션 데이터베이스의 복제본이 필요합니다.
개발자는 App.config 파일에서 해당 데이터베이스의 비밀번호를 갖습니다.
우리는 상기 데이터베이스의 데이터가 손상되는 것을 원하지 않습니다.

몇 가지 제안 된 솔루션 및 단점 :

전체 디스크 암호화. 이것은 모든 문제를 해결하지만 랩탑의 성능을 저하 시키며 우리는 신생 기업이므로 파워 호스를위한 돈이 없습니다.
암호화 된 하드 디스크로 VM을 생성하고 데이터베이스를 저장합니다. Web.Config에 암호가 있기 때문에 잘 작동하지만 너무 도움이되지 않습니다.
솔루션 번호 2 + 개발자는 무언가를 실행할 때마다 데이터베이스 비밀번호를 입력해야합니다. 모든 문제를 해결하지만 때때로 분당 여러 번 응용 프로그램을 시작하는 개발자에게는 번거 롭습니다. 또한 동일한 데이터베이스에 연결되는 여러 응용 프로그램이 있으며 암호 화면의 구현은 각각 다릅니다.

따라서 제 질문은 그러한 문제에 대한 일반적인 해결책이 있거나 위의 해결책 중 어떤 것이 가능하게 만드는 방법에 대한 제안이 있습니까?

database security

— 스바 로그
소스

26

전체 디스크 암호화의 성능 영향을 실제로 측정 했습니까? 상당히 오래된 랩톱에서 사용했지만 성능이 크게 저하되지 않았습니다. 최신 운영 체제는 캐싱 성능이 뛰어나고 디스크 속도가 느립니다. 최악의 영향은 아마도 배터리 수명에 영향을 줄 것입니다.

— 5gon12eder 16:19에

69

솔직히 말해서 이것은 올바른 접근법처럼 들리지 않습니다. 1) 왜 개발자가 컴퓨터에 프로덕션 데이터베이스 가 필요한 가요? dev db에 더미 데이터를 생성하는 방법이 없습니까? 2) 비밀번호가 구성 파일에 일반 텍스트로 저장되는 이유는 무엇입니까? 결함이있는 프로세스에 반창고를 넣으려고합니다. 아마도 개발자 컴퓨터에 실제로 존재하는 내용과 데이터베이스의 암호가 저장되는 방식을 수정할 수 있습니다.

— 토마스 스트링거

2

개발자에게 프로덕션 데이터베이스가 필요한 이유가 있습니다. 역사적 이유로 그들의 작업은 실제 데이터와 너무 연관되어 있습니다. 나는 이것이 나쁜 생각임을 알고 있으며, 좋은 해결책을 찾지 못하면 더미 데이터로 옮길 것입니다. 지금은 그없이 좋은 해결책을 찾으려고 노력하고 있습니다.

— Svarog

6

MacBook Pro 사용자는 SSD 드라이브에서 전체 디스크 암호화가 켜져 있는지 여부를 컴퓨터 속도에서 알 수 없습니다. 차이가 없습니다. 당신이 알아 차릴 수있는 것은 없습니다. 아마도 당신이 측정 할 수는 있지만 눈에 띄는 것은 없습니다.

— gnasher729

5

@ gnasher729의 의견이 두 번째입니다. 규제 된 환경 (금융 및 건강 관리)에서 수년 동안 전체 디스크 암호화를 사용해 왔지만 성능을 현저하게 떨어 뜨릴 필요는 없습니다. 많은 사람들이 다른 유효한 포인트를 제시하지만 HIPAA 환경에서는 데이터베이스가 노트북에 배치되지 않은 경우에도 전체 디스크 암호화없이 합리적인 정책을 세우기가 어렵습니다. 어쨌든 이메일과 다른 데이터 조각이 종종 발생합니다. 스왑 파일 ... 등 ... 전체 디스크 암호화는 충분하지 않지만 일반적으로 필요합니다.

— joshp

100

프로덕션 데이터베이스의 사본을 원하지 않을뿐만 아니라 실제로 불법 일 수도 있습니다. 예를 들어 미국의 경우 개인 건강 데이터, 재무 데이터 또는 신원 도용에 사용될 수있는 데이터와 같은 규제 정보가 포함 된 프로덕션 데이터를 프로덕션 환경 밖으로 이동할 수 없습니다. 그렇게하면 벌금이 부과되고 규정 준수 상태가 상실되어보다 적극적인 감사를 받거나 소송을 제기 할 수도 있습니다.

테스트를 위해 프로덕션 규모의 데이터가 필요한 경우 몇 가지 옵션이 있습니다.

모든 더미 데이터를 생성하십시오. 이것은 소리보다 까다 롭습니다. 현명한 가상 데이터를 생성하는 것은 놀랍도록 어렵고 노동 집약적입니다.
생산 데이터를 익명화하십시오. 더 쉬울 수 있지만주의해서 진행하십시오.

옵션 # 2

프로덕션 환경에서 권한이있는 데이터베이스 관리자는 프로덕션 데이터의 사본을 만듭니다.
여전히 프로덕션 환경에서는 동일한 권한을 가진 관리자가 모든 중요한 데이터를 익명화하는 루틴을 실행합니다. 의심스러운 경우 익명으로 처리하십시오.
그래야만 데이터를 다른 환경으로 옮겨야합니다.

— 코빈 3 월
소스

31

데이터베이스 복사본의 암호는 프로덕션 버전의 암호와 같아서는 안됩니다 ...

— Monica와 Lightness Races

3

"예를 들어, 미국의 경우 규제 정보가 포함 된 생산 환경에서 생산 데이터를 이동할 수 없습니다"무엇? 이것에 대한 소스가 있습니까? 예를 들어, 프로덕션 데이터베이스의 백업을 스테이징 환경의 데이터 또는 개발자 머신의 DB 테스트로 사용할 수 없습니까?

— nanny

12

@nanny 규제 된 데이터를 사용하고 있다면 아닙니다. 예를 들어, 저는 HIPAA 규정에 따라 일했습니다. HIPAA는 "대상 기업은 또한 보호 된 건강 정보가 특정 목적을 위해 사용, 공개 및 요청되는 양을 제한하는 합리적인 최소 필수 정책 및 절차를 구현해야합니다"라고 말합니다. 최소한의 필요한 정책은 일부 해석에 개방되어 있습니다. Google 법률 고문은 개발자가 데이터에 액세스 할 수없는 곳에 민감한 데이터가 포함되도록 엄격하게 해석했습니다. (실제로 업무를 수행해야합니까?) PCI와 같은 재정 준수에도 동일한주의가 적용됩니다.

— 코빈 3 월

4

@nanny 변호사가 아닌 사람의 의견으로 이것을 받아들이십시오. 그러나 제가 이해 한대로, 규칙은 주마다 크게 다릅니다. 내가 함께 일한 법률 고문은 항상주의를 기울여야합니다. 엄밀히 말하면 개발자는 실제 SSN이 의무를 수행하기 위해 필요하지 않으므로 SSN은 해당 SSN이 액세스 할 수없는 보호 된 환경에 살고 있다고 제안합니다. 그래도 내 말을 듣지 마 대한 찾고 변호사 귀하의 장기적인 이익을 최고의 자원이 될 것입니다.

— 코빈 3 월

5

엄밀히 말하면, 정부 업무를 수행하지 않는 한 타이틀 32가 등장하지 않는 한 PPI에 부주의 한 것은 불법이 아닙니다. 그러나 심각한 민사 책임 노출입니다. 그러나 그렇지 않으면 큰 대답입니다. 공감.

— dwoz

9

최소한 데이터 센터의 개발자 VM에게이 작업을 위해 RD를 제공 할 수있는 VM을 제공 할 수 있습니까? 실제로는 프로덕션 이외의 데이터로 작업해야하지만 데이터가 쉽게 도난당한 랩톱에 저장되지 않기 때문에 데이터가 도착할 때까지 더 안전합니다.

— 브라이언 녹 블라 우크
소스

이것은 댓글처럼 더 읽습니다. 답변하는 방법

— gnat

5

@ gnat,이 답변은 짧을 수 있지만 제안 된 대안입니다.

그런 장난을하지 마라. @gnat ... 이것은 좋은 대답이다.

— dwoz

@ dan1111 문제입니다. 답이 아닙니다. 대안입니다. 그것은 대답이 아니라 의견입니다.

— corsiKa

2

@ corsiKa, 질문의 전제에 도전하는 답변은 허용되며 종종 매우 좋은 답변입니다. XY 문제 : meta.stackexchange.com/questions/66377/what-is-the-xy-problem을 참조하십시오 . 더 자세한 답변이 더 나을 수도 있지만 이것은 여전히 답변입니다.

8

가능하면 일하는 방식을 바꾸십시오.

다른 사람들이 지적했듯이 :

개발을 위해 생산 데이터를 사용하는 것은 좋은 습관이 아닙니다.
암호를 일반 텍스트로 저장하는 것은 좋지 않습니다.

이 두 가지 모두 심각한 위험에 노출되므로 가능하면 변경해야합니다. 최소한 이러한 변경 비용이 얼마인지 심각하게 평가해야합니다. 이것이 당신이 변화 할 힘이없는 외부 의존성이라면, 그 힘을 가진 사람에게 관심사로 이것을 제기하는 것을 고려하십시오.

그러나 실제로는이를 변경하는 것이 불가능할 수도 있습니다. 당신이하고있는 일이 합법적이라고 가정하면, 당신은 (적어도 일시적으로)이 약정에 따라 살아야 할 수도 있습니다.

이것이 정말로 필요한 경우 전체 디스크 암호화 만하면됩니다.

위험이있을 경우 최상의 보안 옵션을 사용해야합니다. 이것이 바로 그 것입니다. 퍼포먼스 히트가 있다면 함께하십시오. 민감한 데이터로 작업하는 데 드는 비용입니다.

내가 당신의 고객이라면, 랩탑이 약간 느려졌 기 때문에 내 데이터에 최상의 보안 옵션을 사용하지 않기로 결정했다는 것에 감동하지 않을 것입니다.

1

"아니 이상적인 솔루션"IMO "완전히 바보 같은 생각"를 변경해야합니다

— Darkhogg

@Darkhogg, 당신은 더 강해야 맞습니다. 편집했습니다. 나는 응용 프로그램이 얼마나 민감한 지 알지 못하고 "완전히 바보"가되지 않습니다. 실제로 전체 디스크 암호화를 사용하면 손상 위험이 매우 낮으므로 보안 문제로이를 너무 많이 만들 수 있습니다.

나는 첫 번째 요점에 동의하지만 두 번째 요점에는 동의하지 않습니다. 암호를 일반 텍스트로 저장하지 않는 경우 (1) 암호문 또는 (2) 뇌를 저장하십시오. (1)이면 암호의 암호를 어디에 저장합니까 (무한 루프 감지). (2)이면 오전 2시에 깨어나서 서비스를 다시 시작하기 위해 암호를 입력하기를 바랍니다.

— emory

1

Corbin March의 대답은 꽤 좋습니다. 프로덕션 데이터베이스에는 일반적으로 두 가지 클래스의 데이터가 있습니다. 시스템 / 애플리케이션 메타 데이터; 및 클라이언트 사용자 데이터 / 트랜잭션 데이터. 후자는 "있는 그대로"개발 환경에서 사용해서는 안됩니다.

개발을 위해 실제 프로덕션 클라이언트 정보가 필요한 경우는 매우 드 rare니다.

그러나 여기에서 OP가 설명하는 문제에 영업 비밀 데이터 또는 고객 데이터가 포함되지 않은 독점 시스템 데이터와 관련이있는 경우 개발자가 요구하는 보안 접근 방식에는 db 암호는 어딘가에 리소스 파일에서 일반 텍스트로 유지됩니다. 예를 들어 디스크에 저장되지 않은 일일 비밀번호를 재생성하는 메커니즘이 필요합니다.

— 드와 즈
소스

5

client user data/transactional data... should NEVER be used in a development environment "as is." -이건 나에게 들리지 않는 것 같습니다. 이 배열에서는 특정 고객의 데이터와 관련된 생산 관련 프로그래밍 문제를 해결할 수 없습니다. 또한 실제 라이브 데이터는 테스트 관점에서 매우 유용합니다. 민영화 또는 익명화 노력은 구체적으로 규제되는 데이터에만 집중해야합니다.

— Robert Harvey

@RobertHarvey, 개발 환경에서 프로덕션 문제를 재현 할 수없는 경우에만 작동하지 않습니다. 내 경력에 걸쳐 (길게) 적절하게 위생 처리 된 테스트 데이터가 생산 버그를 재현하기에 적합하지 않은 횟수를 몇 손가락으로 믿을 수 있다고 생각합니다. "독점 비즈니스 정보"는 SSN 및 CC 번호를 훨씬 뛰어 넘습니다!

— dwoz

4

그러나이 경로를 따라갈 계획이라면 모든 사람에게 관리 액세스 권한이 없기 때문에 업무를 수행 할 수없는 IT 직원이 있습니다. 나는 이것이 Snowden 문제를 일으킬 수 있음을 인정하지만, 신뢰할 수있는 사람들을 고용하는 것 외에는 실용적인 대안을 찾지 못했습니다. Sarbanes Oxley와 HIPAA는 어떤 종류의 데이터를 격리해야하는지에 대해 매우 구체적이며, "모든 생산 데이터"를 포함하지는 않습니다. 그러나 로밍 랩톱에는 어떤 종류의 생산 데이터도 존재하지 않을 것이라고 생각합니다.

— Robert Harvey

1

절대로 -1입니다. 더 미묘한 의견은 답변보다 낫습니다. 그것들을 편집해야합니다.

1

@ dan1111 우리는 동의하지 않을 수 있습니다. "있는 그대로"고객 데이터는 절대로 dev 시스템에서 절대 사용해서는 안됩니다. 항상 소독해야합니다. 이 멍청한 몽구스에 물린 적이 없기 때문에 이것을 믿지 않습니다 ... 그리고 그것이 일어날 때 그것이 바로 그 것입니다. 피를 뽑으려고하는 미쳤던 미친 설치류. 내 충고를 들어라.

— dwoz

1

어떤 데이터베이스와 환경을 명시하지 않았습니다.

통합 보안을 사용할 수있는 경우 해당 사용자로 로그인하지 않으면 데이터베이스에 액세스 할 수 없습니다. 예. 데이터가 하드 디스크에있는 경우 해킹 할 수 있지만 이는 1 차 방어입니다.

App.config는 이것이 .NET 일 수 있다고 생각합니다. 썸 드라이브에 구성을 넣고 썸 드라이브에서 읽습니다. 드라이브가 없으면 암호를 입력하십시오.

암호를 처음 입력하고 읽을 때 암호를 메모리에 저장하는 방법이 있습니까? 다시 말하지만 당신은 환경을 진술하지 않습니다. 메모리 매핑 파일

일부 TDE를 사용하면 데이터베이스 서버가 시작될 때 키를 제공하기 위해 별도의 장치에 키를 저장할 수 있습니다.

— 파파 라조
소스

0

가능한 옵션 중 하나는 데이터베이스 사본을 작성하고 스크립트를 사용하여 해당 사본을 제거하여 실제 프로덕션 환경과 다른 데이터로 끝나는 것입니다. 프로덕션과 동일한 데이터로 끝나지 않지만 규모는 동일합니다.

— 제이슨 크로스비
소스

이것은 단지 일주일 전 최고 답변에서 언급 되고 설명 된 반복 된 것으로 보인다

— gnat