데이터 암호화: 개발자가 알아야 할 중요한 용어

세상이 점점 더 데이터 중심적으로 변해감에 따라 사용자 데이터의 안전한 처리가 그 어느 때보다 중요해졌습니다.

개발자로서 우리의 일은 이미 충분히 어렵습니다. 인간의 바램을 UI와 백엔드로 변환하는 동안 여러 실패 지점이 있는 매우 복잡하고 취약한 시스템을 처리하는 것입니다. 이 작업에 추가하는 것은 데이터 보안이라는 새로운 필수 고려 사항입니다. 그리고 정당한 이유가 있습니다. 데이터가 오용되는 경우 고객으로서 분노하고(그래서 사용자에게 안전하고 즐거운 경험을 제공하는 것이 공정합니다) 정부와 기업에서 규정 준수를 요구합니다.

전가로서의 데이터 보안

보안을 더 어렵게 만드는 것은 보안이 여러 겹으로 되어 있어 모두의 책임이 아닌 누구의 책임도 아닌 것이 된다는 것입니다. 최신 클라우드 팀에서는 개발자, 데이터베이스 관리자, 시스템 관리자(원하는 경우 DevOps 직원), 권한 있는 백오피스 사용자 등 여러 팀이 데이터의 수신/송신을 직접 제어합니다. 이러한 역할/팀은 빠르게 눈을 감고 데이터 보안을 다른 사람의 문제로 생각할 수 있습니다. 그러나 현실은 데이터베이스 관리자가 보안의 앱 측면을 제어할 수 없고 DevOps 담당자가 백 오피스 액세스에 대해 아무 것도 할 수 없기 때문에 처리해야 할 자신만의 세계가 있다는 것입니다.

개발자 및 데이터 보안

그렇긴 하지만 개발자는 데이터와 관련하여 가장 큰 액세스 표면적을 가지고 있습니다. 앱의 모든 부분을 빌드합니다. 다양한 백엔드 서비스에 연결합니다. 페리 액세스 토큰 앞뒤; 그들은 명령에 따라 읽고 쓸 전체 데이터베이스 클러스터를 가지고 있습니다. 그들이 작성하는 앱은 시스템의 모든 부분에 대해 의심의 여지 없이 액세스할 수 있습니다. 결과적으로 보안 측면에서 가장 큰 실수나 부주의는 소스 코드 수준에 존재하며 개발자의 직접적인 책임입니다.

이제 데이터 보안은 바닥이 없는 토끼 구멍이고, 단일 게시물에서 표면을 긁을 수 있는 방법도 없습니다. 그러나 개발자가 앱을 안전하게 유지하기 위해 알아야 하는 필수 용어를 다루고 싶습니다. App Data Security 101이라고 생각하시면 됩니다.

시작하자!

해싱

매우 엄격한 정의를 원하면 항상 Wikipedia가 있지만 간단히 말해서 해싱은 정보를 읽을 수 없는 다른 형식으로 데이터를 변환하는 프로세스입니다. 예를 들어, 잘 알려진(매우 안전하지 않은) Base64 인코딩 프로세스를 사용하여 "내 비밀이 안전합니까?"라는 문자열을 사용합니다. "SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/"로 변환("해시")될 수 있습니다. 예를 들어 Base64 형식으로 개인 일기를 쓰기 시작하면 가족이 귀하의 비밀을 읽을 수 있는 방법이 없습니다(Base64에서 해독하는 방법을 모르는 경우)!

이러한 데이터 스크램블링 아이디어는 웹 앱에서 비밀번호, 신용 카드 번호 등을 저장할 때 사용됩니다(실제로 모든 유형의 앱에서 사용해야 함). 물론 아이디어는 데이터 침해가 발생한 경우 공격자가 암호, 신용 카드 번호 등을 사용하여 실제 피해를 입힐 수 없어야 한다는 것입니다. 매우 강력하고 정교한 알고리즘이 이 해싱을 수행하는 데 사용됩니다. Base64와 같은 것은 농담이 될 것이며 모든 공격자에 의해 즉시 중단될 것입니다.

암호 해싱은 단방향 해싱으로 알려진 암호화 기술을 사용합니다. 즉, 데이터를 스크램블할 수는 있지만 스크램블 해제는 불가능합니다. 그러면 로그인할 때 앱이 비밀번호를 어떻게 알 수 있습니까? 글쎄, 그것은 동일한 프로세스를 사용하고 데이터베이스에 저장된 스크램블된 형식과 암호로 방금 입력한 것의 스크램블된 형식을 비교합니다. 일치하면 로그인할 수 있습니다!

우리가 해시에 대해 이야기하는 동안 여기에 흥미로운 것이 있습니다. 인터넷에서 소프트웨어나 파일을 다운로드한 적이 있다면 사용하기 전에 파일을 확인하라는 지시를 받았을 것입니다. 예를 들어 Ubuntu Linux ISO를 다운로드하려는 경우 다운로드 페이지에 다운로드를 확인하는 옵션이 표시됩니다. 클릭하면 팝업이 열립니다.

: 팝업은 기본적으로 다운로드 한 전체 파일을 해시하고 다운로드 페이지에 표시되는 해시 문자열로 결과를 비교하는 것입니다 명령을 실행 할 것을 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 . 이 변환은 명령의 마지막 부분에서 볼 수 있는 SHA256 알고리즘을 사용하여 수행됩니다. shasum -a 256 --check .

수표를 통해 생성된 해시가 다른 경우 누군가가 다운로드에 개입하여 손상된 파일을 대신 제공했다는 의미입니다.

암호 해싱 영역에서 듣게 될 친숙한 이름으로는 MD5(안전하지 않고 현재는 사용되지 않음), SHA-1 및 SHA-2(SHA-256이 SHA-512와 같은 구성원인 알고리즘 제품군)가 있습니다. 스크립트, BCRYPT 등

염장

모든 유형의 보안은 고양이와 쥐 게임입니다. 도둑은 현재 시스템을 학습하고 새로운 크랙을 찾아내고 이를 알아차리고 잠금 장치 제작자는 게임을 개선하는 식입니다. 암호화도 예외는 아닙니다. 해시를 다시 암호로 변환하는 것이 불가능해졌지만 시간이 지남에 따라 공격자는 지능형 추측과 순수한 계산 능력을 결합한 정교한 기술을 개발했습니다. 결과적으로 10번 중 9번은 해시만 주어지면 올바른 암호를 예측할 수 있습니다.

결과적으로 염장 기술이 개발되었습니다. 이것이 의미하는 것은 암호(또는 모든 데이터)의 해시 계산이 데이터 자체와 공격자가 추측할 수 없는 새로운 임의의 문자열이라는 두 가지 조합을 기반으로 수행된다는 것입니다. 따라서 bCQC6Z2LlbAsqj77 을 사용하여 암호 superman009 를 해시하려면 먼저 임의의 문자열을 "솔트"로 선택합니다(예: bCQC6Z2LlbAsqj77 그런 다음 superman009-bCQC6Z2LlbAsqj77 에서 해시 계산을 수행합니다. 결과 해시는 알고리즘에 의해 생성된 일반적인 구조에서 벗어나 지능형 리버스 엔지니어링 또는 추측의 범위를 크게 줄입니다.

해싱(Hashing)과 솔팅(Salting)은 모두 엄청나게 복잡한 영역이며 지속적으로 진화하고 있습니다. 따라서 응용 프로그램 개발자로서 우리는 절대 그들과 직접적으로 거래하지 않습니다. 그러나 우리가 이것을 알고 더 나은 결정을 내릴 수 있다면 큰 도움이 될 것입니다. 예를 들어, 이전 PHP 프레임워크를 유지 관리하고 비밀번호에 MD5 해시를 사용하는 것을 보게 되면 사용자 계정 생성 프로세스에 다른 비밀번호 라이브러리를 삽입해야 할 때임을 알 수 있습니다.

열쇠

암호화와 관련하여 "키"라는 용어를 자주 접하게 됩니다. 지금까지 우리는 데이터를 되돌릴 수 없도록 변환하고 원래 형태를 파괴하는 암호 해싱 또는 단방향 암호화에 대해 다루었습니다. 이것은 일상적으로 사용하기에 좋지 않은 생각입니다. 절대 읽을 수 없을 정도로 안전하게 작성되고 이메일로 전송된 문서는 아무 소용이 없습니다! 따라서 우리는 정보가 발신자와 수신자에게 공개되기를 원하지만 전송 중이거나 저장되는 동안 읽을 수 없도록 데이터를 암호화하려고 합니다.

이를 위해 암호화에는 "키"라는 개념이 존재합니다. 그것은 정확히 소리가 나는 것과 같습니다: 자물쇠의 열쇠. 정보를 소유한 사람은 키라는 비밀을 사용하여 정보를 스크램블합니다. 수신자/공격자에게 이 키가 없으면 알고리즘이 아무리 정교하더라도 데이터를 해독할 수 없습니다.

회전 키

키는 암호화를 가능하고 안정적으로 만들지만 암호에는 위험이 따릅니다. 누군가가 키를 알게 되면 전체 게임이 시작됩니다. 누군가가 GitHub와 같은 서비스의 일부를 해킹하고(몇 초 동안이라도) 20년 된 코드를 보유할 수 있는 시나리오를 상상해 보십시오. 코드 내에서 회사 데이터를 암호화하는 데 사용되는 암호화 키도 찾습니다(소스 코드와 함께 키를 저장하는 것은 끔찍한 관행이지만 이러한 일이 얼마나 자주 발생하는지 놀라게 될 것입니다!). 회사가 (비밀번호와 마찬가지로) 키를 변경하는 데 신경 쓰지 않았다면 동일한 키를 사용하여 혼란을 일으킬 수 있습니다.

결과적으로 키를 자주 변경하는 관행이 발전했습니다. 이것을 키 순환이라고 하며, 존경할만한 클라우드 PaaS 제공업체를 사용하고 있다면 자동화된 서비스로 제공되어야 합니다.

예를 들어 AWS에는 AWS Key Management Service(KMS)라는 전용 서비스가 있습니다. 자동화된 서비스를 사용하면 모든 서버에서 키를 변경하고 배포하는 번거로움을 줄일 수 있으며 대규모 배포와 관련하여 요즘은 쉬운 일이 아닙니다.

공개 키 암호화

암호화와 키에 대한 이전의 모든 이야기가 매우 번거롭다고 생각하게 만든다면, 당신이 옳습니다. 수신자만 데이터를 볼 수 있도록 키를 안전하게 유지하고 전달하면 오늘날의 보안 통신이 번성할 수 없는 물류 문제가 발생합니다. 그러나 모두 공개 키 암호화 덕분에 온라인에서 안전하게 통신하거나 구매할 수 있습니다.

이러한 유형의 암호화는 중요한 수학적 돌파구였으며 인터넷이 두려움과 불신으로 무너지지 않는 유일한 이유입니다. 알고리즘의 세부 사항은 복잡하고 매우 수학적이므로 여기서는 개념적으로만 설명할 수 있습니다.

공개 키 암호화는 두 개의 키를 사용하여 정보를 처리합니다. 키 중 하나는 개인 키(Private Key)라고 하며 귀하와 비공개로 유지되어야 하며 누구와도 공유되지 않아야 합니다. 다른 하나는 공개 키(메소드 이름이 유래)라고 하며 공개적으로 게시되어야 합니다. 내가 데이터를 보내려면 먼저 공개 키를 가져와서 데이터를 암호화하여 보내야 합니다. 결국 개인 키와 공개 키 조합을 사용하여 데이터를 해독할 수 있습니다. 실수로 개인 키를 공개하지 않는 한, 귀하만 열 수 있는 암호화된 데이터를 보내드릴 수 있습니다.

이 시스템의 장점은 내가 당신의 개인 키를 알 필요가 없고 메시지를 가로채는 사람이 당신의 공개 키를 가지고 있어도 메시지를 읽기 위해 아무 것도 할 수 없다는 것입니다. 이것이 어떻게 가능한지 궁금하다면 가장 짧고 가장 비기술적인 대답은 소수의 곱셈 속성에서 나옵니다.

컴퓨터가 큰 소수를 인수분해하는 것은 어렵습니다. 따라서 원본 키가 매우 크면 수천 년 후에도 메시지를 해독할 수 없다고 확신할 수 있습니다.

TLS(전송 계층 보안)

이제 공개 키 암호화가 어떻게 작동하는지 알게 되었습니다. 이 메커니즘(수신자의 공개 키를 알고 이를 사용하여 암호화된 데이터 전송)은 모든 HTTPS 인기의 배후이며 Chrome에서 "이 사이트는 안전합니다."라고 말하는 원인입니다. 서버와 브라우저가 서로의 공개 키로 HTTP 트래픽(웹 페이지는 브라우저가 해석할 수 있는 매우 긴 텍스트 문자열임을 기억하십시오)을 암호화하여 보안 HTTP(HTTPS)가 생성됩니다.

이미지 크레디트: Mozilla전송 계층에서 암호화가 발생하지 않는다는 점은 흥미롭습니다. OSI 모델은 데이터 암호화에 대해 아무 말도 하지 않습니다. 단지 데이터가 전송 계층으로 전달되기 전에 애플리케이션(이 경우 브라우저)에 의해 암호화되며, 전송 계층은 나중에 목적지에서 이를 복호화합니다. 그러나 프로세스에는 전송 계층이 포함되며 결국 모든 것이 데이터의 안전한 전송으로 이어지므로 "전송" 계층 보안이라는 느슨한 용어가 사용됩니다.

경우에 따라 SSL(Secure Socket Layer)이라는 용어를 접할 수도 있습니다. SSL이 훨씬 이전에 시작되었고 현재 TLS를 선호하여 종료되었다는 점을 제외하고는 TLS와 동일한 개념입니다.

전체 디스크 암호화

때로는 보안 요구 사항이 너무 강해서 아무 것도 우연에 맡길 수 없습니다. 예를 들어, 국가의 모든 생체 데이터가 저장된 정부 서버는 위험이 너무 높기 때문에 일반 애플리케이션 서버처럼 프로비저닝하고 실행할 수 없습니다. 데이터를 전송할 때만 암호화하는 것만으로는 이러한 요구 사항을 충족할 수 없습니다. 휴지 상태일 때도 암호화해야 합니다. 이를 위해 전체 디스크 암호화를 사용하여 하드 디스크 전체를 암호화하여 물리적으로 침해된 경우에도 데이터를 안전하게 보호합니다.

전체 디스크 암호화는 하드웨어 수준에서 수행되어야 합니다. 전체 디스크를 암호화하면 운영 체제도 암호화되어 시스템이 시작될 때 실행할 수 없기 때문입니다. 따라서 하드웨어는 디스크 내용이 암호화되어 있고 요청된 디스크 블록을 운영 체제로 전달할 때 즉석에서 암호 해독을 수행해야 한다는 것을 이해해야 합니다. 이 추가 작업이 수행되기 때문에 전체 디스크 암호화를 사용하면 읽기/쓰기 속도가 느려지므로 이러한 시스템 개발자는 이를 염두에 두어야 합니다.

종단 간 암호화

오늘날 대규모 소셜 네트워크의 개인 정보 보호 및 보안 악몽이 계속됨에 따라 앱 제작 또는 유지 관리와 관련이 없는 경우에도 "종단 간 암호화"라는 용어를 모르는 사람은 없습니다.

앞에서 전체 디스크 암호화가 궁극적인 방탄 전략을 제공하는 방법을 보았지만 일반 사용자에게는 편리하지 않습니다. 내 말은, Facebook이 생성하여 휴대전화에 저장하는 휴대전화 데이터의 보안을 원하지만 전체 휴대전화를 암호화하고 그 과정에서 다른 모든 것을 잠그는 데 액세스할 수 없다고 상상해 보세요.

이러한 이유로 이러한 회사는 데이터가 앱에서 생성, 저장 또는 전송할 때 암호화되는 종단 간 암호화를 시작했습니다. 즉, 데이터가 수신자에게 도달하더라도 완전히 암호화되어 수신자의 전화로만 액세스할 수 있습니다.

E2E(End-to-End) 암호화는 공개 키 암호화와 같은 수학적 보장을 제공하지 않습니다. 비즈니스와 함께 키가 저장되는 표준 암호화일 뿐이며 메시지는 비즈니스가 결정하는 만큼 안전합니다.

결론

이러한 용어의 대부분은 이미 들어보았을 것입니다. 어쩌면 그들 모두일 수도 있습니다. 그렇다면 이러한 개념에 대한 이해를 다시 한 번 검토하고 이를 얼마나 진지하게 받아들이는지 평가해 보시기 바랍니다. 앱 데이터 보안은 한 번이 아니라 매번 승리해야 하는 전쟁입니다. 한 번의 침해로도 전체 산업, 경력, 심지어 삶을 파괴하기에 충분하기 때문입니다.