개발자의 민감한 데이터 보안

MySQL 및 MongoDB 데이터 저장소를 모두 사용하는 엔터프라이즈 응용 프로그램이 실행 중입니다 . 내 개발 팀은 모두 애플리케이션 릴리스, 유지 보수 등을 수행하기 위해 머신에 대한 SSH 액세스 권한을 가지고 있습니다.

최근에 사용자가 응용 프로그램에 매우 민감한 데이터를 저장하기 시작했을 때 개발자가이 데이터에 간접적으로 액세스하여 약간의 폭풍이 발생 했으므로 비즈니스가 위험에 처하게되었으므로 이제는 데이터를 안전하게 보호해야합니다. 얻기 쉬운.

응용 프로그램이 데이터베이스에 액세스 할 수 있으면 머신 및 응용 프로그램 소스에 액세스 할 수있는 개발자가 항상 데이터에 액세스 할 수 있기 때문에 나에게는 이것이 불가능 해 보입니다.

보안은 프로젝트가 끝날 때 흔들릴 수있는 마술 지팡이가 아니며, 1 일부터 고려하여 구축해야합니다. 볼트 방식이 아니며, 반복적으로 적용되고 검토 된 다양한 솔루션의 일관된 적용입니다. 정기적으로 전체 시스템의 일부로서 가장 약한 링크만큼 강력합니다.

현재로서는 보안에 대한 우려를 표명했습니다. 이는 첫 번째 단계입니다. 이제 최소한 다음을 정의해야합니다.

• 어떤 데이터를 보호하려고합니까?
• 누가 그 데이터를 보호하려고합니까?
• 실제로 누가 언제 무엇에 액세스해야합니까?
• 해당 데이터에 대한 법적 / 재정적 / 비즈니스 영향은 무엇입니까?
• 데이터에 액세스 할 수있는 개인 / 그룹에 대한 법적 / 재정적 / 비즈니스 요구 사항은 무엇입니까?
• 비즈니스가 이전에 비즈니스 요구 사항이 아니었을 때 "보안 유지, 보안 유지"전략에 할당하려는 예산은 얼마입니까?
• 시스템에 데이터에 대한 액세스가 필요합니까?
• 이 응용 프로그램이 의존하는이 프로세스와 시스템은 무엇입니까?
• 그러한 환경을 보호하기 위해 무엇을해야합니까?
• 이를 구현하고 전체 프로세스를 검토 할 책임은 누구에게 있습니까?

모든 것을 자세히 알기 전까지는 실제로 작업 할 것이 없습니다. 이 정보는 적용 할 수있는 (및 불가능한) 위협에 대한 완화 조치와 이유를 정의합니다.

최선의 방법은 당신이 필요한 경험이없고 그 경험을 가진 새로운 사람을 데려 오는 것이 최선이라는 것을 인식하는 것입니다. 예산이 없다는 응답을 자주 듣습니다. 실제로 중요하다고 생각되면 예산을 찾을 수 있습니다.

네 말이 맞아 사용자가 매번 추가 정보를 전달하지 않고 애플리케이션이 회사 시스템에 저장된 컨텐츠에 액세스 할 수있는 경우 서비스 제공자의 프로그래머, 유지 보수 자, 시스템 관리자 등이 해당 컨텐츠에 액세스 할 수 있습니다. 이것은 근본적으로 불가피하고 불안정한 주요 원인입니다 (Edward Snowden은 시스템 관리자였으며 단순히 권한을 부여 할 수있는 방법이 없기 때문에 "Top Secret"보다 특별한 권한을 가졌습니다.)

이를 피할 수있는 유일한 방법은 사용자가 회사 컴퓨터에 절대 정보를 제공하지 않도록하는 것입니다. 보안 액세스 장벽을 형성하기에 충분한 정보를 기억할 수 없기 때문에 사람들은 즉시 자격 증명을 전자적인 장소에 저장하기 시작하여 새로운 공격 대상이 될 것입니다. 유지하려는 대상보다 약한 대상). 그러나 "직원이 물리적으로 사용자의 콘텐츠에 액세스 할 수는 없습니다"라고 진실되게 주장하려면 이것이 유일한 방법입니다.

(이러한 비즈니스 모델은 정치적으로 불가능한 것으로 보입니다. 비즈니스는 정확히 이것을 시도하기 위해 보안 서비스에 의해 운영이 중단되었습니다. 개인 정보 보장을 제공하는 것은 비즈니스 가치가 있지만 더 많은 것을 가질 수는 없다는 것을 이해합니다 비즈니스를 유지하려는 기본 목표보다 비즈니스 가치.)

당신 말이 맞아요. 일부 개발자는 프로덕션 문제를 진단하기 위해 항상 라이브 데이터에 액세스해야합니다. 당신이 할 수있는 최선의 방법은 관련된 사람들의 수를 줄여 잠재적 인 피해를 제한하는 것입니다.

With great power comes great ... opportunity to really, *really* foul things up. 

많은 개발자들은 그러한 책임과 다른 사람들을 원하지 않을 것입니다. 단지 책임을지지 않을 준비가되어 있지 않아야합니다.

질문 : 개발 팀에서 라이브 릴리스를 수행하는 이유는 무엇 입니까?
릴리스 관리 "팀"(팀의 일부일뿐 아니라 "Go / No-Go"와 같은 일상적인 "결정"을 내리기위한 비즈니스 표현)도 필요하십니까? 개발자가 터치를 위해 이것은 "필요성"의 대부분을 제거 할 것을 라이브.

개발자와 회사간에 비밀 유지 / 비밀 계약이 있습니까? 손이 많지만 장점이있을 수 있습니다.

문제는 개발자가 시스템에 액세스 할 수 있다는 것입니다. 디버깅에 프로덕션 데이터가 필요한 경우 민감한 정보가 모두 제거 된 데이터베이스 덤프를 제공하십시오. 그런 다음 개발자는 해당 덤프로 작업 할 수 있습니다.

새 버전을 배포 할 때는 개발자, 즉 순수한 관리 작업 또는 완전 자동화 된 작업이 필요하지 않습니다. 또한 두 가지 매우 다른 작업 인 릴리스 및 배포에 유의하십시오. 프로세스가이를 인식하지 못하면 적절히 변경하십시오.

보안 규칙 # 1 : 누군가 정보에 액세스 할 수있는 경우 해당 정보에 액세스 할 수 있습니다

그 긴장은 성가 시지만 사실입니다. 개인에게 액세스 권한을 부여하면 데이터에 액세스 할 수 있습니다. 사용자에게는 일반적으로 액세스 제어를 의미하지만 개발자에게는 ... 액세스 제어를 작성해야하는 사람들입니다.

이것이 당신에게 중요한 문제라면 (그리고 그 소리처럼 들리면) 소프트웨어에 보안을 구축하는 것을 고려하십시오. 일반적인 패턴은 보안 소프트웨어를 레이어로 디자인하는 것입니다. 가장 낮은 계층에서 신뢰할 수있는 개발 팀은 가장 알기 쉬운 액세스 제어를 관리하는 소프트웨어를 설계합니다. 이 소프트웨어는 가능한 많은 사람들이 검증하고 검증합니다. 해당 코드를 디자인하는 사람은 누구나 모든 것에 액세스 할 수 있으므로 신뢰가 필수적입니다.

그 후 개발자는 해당 핵심 계층 위에보다 유연한 액세스 제어를 구축 할 수 있습니다. 이 코드는 여전히 V & Vd 여야하지만 필수 사항을 다루기 위해 항상 코어 계층에 의존 할 수 있기 때문에 엄격하지는 않습니다.

패턴이 바깥쪽으로 확장됩니다.

어려운 부분, 실제로 예술 이 시스템 설계는 아직도 당신이 기대하는 보안 기업을 제공하면서 개발자는 개발을 계속하고 디버그 할 수 있도록 각 레이어를 구축하는 방법이다. 특히, 디버깅이 동의해야합니다 요구 당신이해야한다고 생각하고, 매우 화가 개발자가 발생합니다 그 아래를 잠그면보다 더 많은 권한을.

부수적 인 솔루션으로 개발자가 모든 안전 메커니즘을 제거하고 심각한 디버깅을 수행 할 수있는 테스트 목적으로 "안전한"데이터베이스를 만드는 것이 좋습니다.

결국, 개발자와 개발자 모두 주요 보안 원칙을 이해해야합니다. 모든 보안은 보안과 유용성의 균형입니다. 당신은 해야한다 회사로 자신의 균형을. 시스템은 완벽하게 안전하지 않으며 완벽하게 사용할 수 없습니다. 회사가 성장하거나 개발자에 대한 요구가 변화함에 따라 이러한 균형이 달라질 수 있습니다. 이 현실에 개방적이라면이를 해결할 수 있습니다.

분리 된 데이터베이스 배치를 사용하는 두 개의 애플리케이션 배치를 설정하십시오. 하나는 프로덕션 배포이고 다른 하나는 테스트 배포입니다.

테스트 배포에는 테스트 데이터 만 있어야합니다. 이는 해당 목적을 위해 생성 된 판타지 데이터이거나 개발자가 데이터 뒤에있는 실제 사람과 엔티티를 찾을 수 없도록 익명화 된 프로덕션 데이터의 사본 일 수 있습니다.

두 금융 회사에서 개발자는 프로덕션 머신에 액세스 할 수 없었습니다. 프로덕션 머신을 수정하기위한 모든 요청은 스크립트를 사용하여 승인 프로세스를 거쳐야했으며 관리자가 승인했습니다. 개발자 팀은 실제 배포를 완료했습니다. 나는이 팀이 직원 일 뿐이며 신원 조회를 통과했다고 생각합니다. 또한 개발자 지식이 없으므로 원하는 경우 스누핑 할 수 없습니다. 이 외에도 환경 변수에 저장된 비밀 키를 사용하여 모든 데이터베이스 항목을 암호화합니다. 데이터베이스가 공개적으로 유출 되더라도 아무도 읽을 수 없습니다. 이 키는 추가 암호로 보호 (PBKDF) 될 수 있으므로 임원 만 잠금을 해제 할 수 있습니다. 부팅시 시스템에 임원 암호가 필요할 수 있습니다 (또는 dev-ops 또는 dev-ops 관리자에게 위임 될 가능성이 높음). 기본적으로 전략은 지식을 분산시켜 한 사람에게 중요한 지식이 존재하지 않으며 점검과 균형이 유지되도록하는 것입니다. 이것이 코카콜라가 공식을 보호하는 방법입니다. 솔직히 이러한 답변 중 일부는 cop-out입니다.

MongoDB는 보안 제어가 제한되어 있으며 안전한 환경에 의존합니다. 특정 IP 및 포트 (2.2 이후 ssl)에 대한 바인딩과 조잡한 인증은 그것이 제공하는 것입니다. MYSQL은 GRANT o ON db.t TO ...를 추가합니다. 미사용 데이터는 암호화되지 않으며 ssl은 기본적으로 사용되지 않습니다. 울타리를 만듭니다. 응용 프로그램 관련 로그 파일에 대한 개발자의 읽기 전용 액세스는 디버그하기에 충분해야합니다. 응용 프로그램 수명주기를 자동화하십시오.

Ansible은 여러 단일 테넌트 환경에서 표준 운영 (배포, 업그레이드, 복원)을 자동화하는 동시에 고유 한 암호화 된 볼트를 사용하여 호스트, 포트 및 자격 증명과 같은 민감한 환경 변수를 저장하는 데 도움이되었습니다. 로깅 된 작업에 대해 각 볼트를 다른 역할 및 배스 천 호스트에서만 해독 할 수있는 경우 감사 기능은 허용 가능한 보안을 제공합니다. SSH를 부여한 경우 selinux를 사용하여 키 변조를 방지하고 관리를 위해 ldap / kerberos 인증이있는 요새 호스트를 사용하고 현명하게 sudo를 사용하십시오.