세상이 점점 더 데이터 중심이 되어감에 따라 사용자 데이터의 안전한 처리가 그 어느 때보다 중요해졌습니다.
개발자로서 우리의 작업은 이미 충분히 어렵습니다. 여러 실패 지점이 있는 매우 복잡하고 취약한 시스템을 처리하는 동시에 인간의 바람을 UI 및 백엔드로 변환합니다. 작업에 추가하는 것은 새로운 필수 고려 사항인 데이터 보안입니다. 그리고 그만한 이유가 있습니다. 데이터가 오용되면 고객으로서 분노하고(그래서 사용자에게 안전하고 즐거운 경험을 제공하는 것이 공정합니다) 정부와 기업은 규정 준수를 요구합니다.
목차
전가로서의 데이터 보안
보안을 더 어렵게 만드는 것은 보안에 여러 계층이 있고 모든 사람의 책임은 누구에게도 책임이 없다는 것입니다. 최신 클라우드 팀에서는 개발자, 데이터베이스 관리자, 시스템 관리자(원하는 경우 DevOps 직원), 권한이 있는 백오피스 사용자 등 여러 팀이 데이터의 수신/발신을 직접 제어합니다. 이러한 역할/팀은 빠르게 눈을 감고 데이터 보안을 다른 사람의 문제로 생각할 수 있습니다. 하지만 현실은 데이터베이스 관리자가 보안의 앱 측면을 제어할 수 없고 DevOps 직원이 백오피스 액세스에 대해 전혀 할 수 없는 등 처리해야 할 자신만의 세계가 있다는 것입니다.
개발자 및 데이터 보안
즉, 개발자는 데이터와 관련하여 가장 큰 액세스 영역을 가지고 있습니다. 개발자는 앱의 모든 부분을 빌드합니다. 그들은 다양한 백엔드 서비스에 연결합니다. 페리 액세스 토큰 앞뒤로; 명령에 따라 읽고 쓸 수 있는 전체 데이터베이스 클러스터가 있습니다. 그들이 작성하는 앱은 의심할 여지 없이 시스템의 모든 부분에 액세스할 수 있습니다. 결과적으로 보안 측면에서 허술함이나 부주의의 가능성이 가장 높은 것은 소스 코드 수준에 존재하며 개발자의 직접적인 책임입니다.
이제 데이터 보안은 밑바닥이 없는 토끼 굴이며 단일 게시물에서 표면을 긁을 수 있는 방법이 없습니다. 그러나 개발자가 앱을 안전하게 유지하기 위해 알아야 하는 필수 용어를 다루고자 합니다. 앱 데이터 보안 101이라고 생각하세요.
시작하자!
해싱
매우 엄격한 정의를 원한다면 항상 위키백과, 그러나 간단히 말해서 해싱은 정보를 읽을 수 없는 다른 형식으로 데이터를 변환하는 프로세스입니다. 예를 들어, 잘 알려진(그리고 매우 안전하지 않은) 프로세스를 사용하여 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번은 해시만 주어지면 올바른 암호를 예측할 수 있습니다.
“씨. Rumpelstiltskin, 아마?!”
그 결과 소금에 절이는 기술이 발전했습니다. 암호(또는 모든 데이터)의 해시 계산은 데이터 자체와 공격자가 추측할 수 없는 새로운 임의 문자열의 조합을 기반으로 수행된다는 의미입니다. 따라서 솔팅을 사용하여 비밀번호 superman009를 해시하려면 먼저 무작위 문자열을 “소금”으로 선택합니다. 결과 해시는 알고리즘에 의해 생성된 일반적인 구조에서 벗어나 지능형 리버스 엔지니어링 또는 추측의 범위를 크게 줄입니다.
해싱과 솔팅은 모두 매우 복잡한 도메인이며 지속적으로 발전하고 있습니다. 따라서 애플리케이션 개발자로서 우리는 이들과 직접 거래하지 않습니다. 하지만 우리가 이것을 알고 더 나은 결정을 내릴 수 있다면 큰 도움이 될 것입니다. 예를 들어, 이전 PHP 프레임워크를 유지하고 있는데 암호에 MD5 해시를 사용하는 것을 보게 되면 사용자 계정 생성 프로세스에 또 다른 암호 라이브러리를 삽입해야 할 때임을 알 수 있습니다.
열쇠
암호화와 관련하여 “키”라는 용어를 자주 접하게 될 것입니다. 지금까지 우리는 데이터를 비가역적으로 변환하고 원래 형식을 파괴하는 암호 해싱 또는 단방향 암호화를 다루었습니다. 이것은 일상적인 사용에 나쁜 생각입니다. 절대 읽을 수 없을 정도로 안전하게 작성되고 이메일로 전송되는 문서는 아무 소용이 없습니다! 따라서 우리는 정보가 발신자와 수신자에게 공개되길 원하지만 정보가 전송되거나 저장되는 동안에는 읽을 수 없도록 데이터를 암호화하려고 합니다.
이를 위해 암호화에는 “키”라는 개념이 존재합니다. 소리는 정확히 같습니다: 자물쇠의 열쇠. 정보를 소유한 사람은 키라고 하는 비밀을 사용하여 정보를 뒤섞습니다. 수신자/공격자가 이 키를 가지고 있지 않으면 알고리즘이 아무리 정교하더라도 데이터를 해독하는 것은 불가능합니다.
회전 키
키는 암호화를 가능하고 안정적으로 만들지만 암호와 같은 위험을 수반합니다. 누군가 키를 알게 되면 전체 게임이 시작됩니다. 누군가가 GitHub와 같은 서비스의 일부를 (몇 초라도) 해킹하여 20년 된 코드를 손에 넣을 수 있는 시나리오를 상상해 보십시오. 코드 내에서 그들은 또한 회사의 데이터를 암호화하는 데 사용되는 암호화 키를 찾습니다(소스 코드와 함께 키를 저장하는 끔찍한 관행이지만 얼마나 자주 이런 일이 발생하는지 놀라실 것입니다!). 회사에서 암호와 마찬가지로 키를 변경하지 않은 경우 동일한 키를 사용하여 대혼란을 일으킬 수 있습니다.
결과적으로 키를 자주 변경하는 방식이 발전했습니다. 이를 키 순환이라고 하며, 신뢰할 수 있는 클라우드 PaaS 공급자를 사용하는 경우 자동화된 서비스로 사용할 수 있어야 합니다.
이미지 크레디트: AWS
예를 들어 AWS에는 이를 위한 전용 서비스가 있습니다. AWS 키 관리 서비스(KMS). 자동화된 서비스는 모든 서버 간에 키를 변경하고 배포하는 번거로움을 줄여주며 요즘에는 대규모 배포와 관련하여 생각할 필요가 없습니다.
공개 키 암호화
암호화와 키에 대한 이전의 모든 이야기로 인해 매우 번거롭다고 생각했다면 맞습니다. 키를 안전하게 유지하고 수신자만 데이터를 볼 수 있도록 키를 전달하면 오늘날의 보안 통신이 번창할 수 없는 물류 문제가 발생합니다. 그러나 공개 키 암호화 덕분에 온라인에서 안전하게 통신하거나 구매할 수 있습니다.
이러한 유형의 암호화는 주요한 수학적 돌파구였으며 인터넷이 두려움과 불신으로 무너지지 않는 유일한 이유입니다. 그만큼 알고리즘의 세부 사항 복잡하고 고도로 수학적이므로 여기서는 개념적으로만 설명할 수 있습니다.
이미지 크레디트: 전자 프론티어 재단
공개 키 암호화는 정보를 처리하기 위해 두 개의 키를 사용합니다. 키 중 하나는 개인 키라고 하며 귀하에게 비공개로 유지되고 누구와도 공유되지 않아야 합니다. 다른 하나는 공개 키(메서드 이름의 유래)라고 하며 공개적으로 게시되어야 합니다. 데이터를 보내려면 먼저 공개 키를 가져와서 데이터를 암호화하여 보내야 합니다. 마지막에는 개인 키와 공개 키 조합을 사용하여 데이터를 해독할 수 있습니다. 실수로 개인 키를 공개하지 않는 한 귀하만 열 수 있는 암호화된 데이터를 보내드릴 수 있습니다.
시스템의 장점은 내가 귀하의 개인 키를 알 필요가 없으며 메시지를 가로채는 사람이 귀하의 공개 키를 가지고 있더라도 메시지를 읽을 수 없다는 것입니다. 이것이 어떻게 가능한지 궁금하다면 소수 곱셈의 속성에서 가장 짧고 가장 비기술적인 대답을 얻을 수 있습니다.
컴퓨터가 큰 소수를 인수분해하는 것은 어렵습니다. 따라서 원래 키가 매우 크면 수천 년이 지나도 메시지를 해독할 수 없다고 확신할 수 있습니다.
TLS(전송 계층 보안)
이제 공개 키 암호화가 어떻게 작동하는지 알게 되었습니다. 이 메커니즘(수신자의 공개 키를 알고 이를 사용하여 암호화된 데이터를 보내는 것)은 모든 HTTPS 인기의 배후에 있으며 Chrome이 “이 사이트는 안전합니다.”라고 말하는 이유입니다. 서버와 브라우저가 서로의 공개 키를 사용하여 HTTP 트래픽(웹 페이지는 브라우저가 해석할 수 있는 매우 긴 텍스트 문자열임을 기억하십시오)을 암호화하여 보안 HTTP(HTTPS)를 생성합니다.
이미지 크레디트: Mozilla암호화는 전송 계층에서 발생하지 않는다는 점이 흥미롭습니다. 그만큼 OSI 모델 데이터 암호화에 대해서는 아무 말도 하지 않습니다. 단지 데이터가 전송 계층으로 전달되기 전에 응용 프로그램(이 경우 브라우저)에 의해 암호화되고 나중에 해당 데이터가 해독되는 대상에 놓이게 됩니다. 그러나 이 프로세스에는 전송 계층이 포함되며 결국 모든 것이 데이터의 안전한 전송으로 이어지므로 “전송” 계층 보안이라는 느슨한 용어가 사용되었습니다.
경우에 따라 SSL(Secure Socket Layer)이라는 용어를 접하게 될 수도 있습니다. TLS와 동일한 개념입니다. 단, SSL은 훨씬 이전에 시작되었고 현재는 TLS로 대체되었습니다.
전체 디스크 암호화
때로는 보안 요구가 너무 강해서 아무 것도 운에 맡길 수 없습니다. 예를 들어 국가의 모든 생체 데이터가 저장되는 정부 서버는 위험이 너무 높기 때문에 일반 애플리케이션 서버처럼 프로비저닝 및 실행될 수 없습니다. 데이터가 전송될 때만 암호화되는 것은 이러한 요구에 충분하지 않습니다. 유휴 상태일 때도 암호화해야 합니다. 이를 위해 전체 디스크 암호화를 사용하여 하드 디스크 전체를 암호화하여 물리적으로 침해된 경우에도 데이터를 안전하게 보호합니다.
전체 디스크 암호화는 하드웨어 수준에서 수행되어야 한다는 점에 유의하는 것이 중요합니다. 전체 디스크를 암호화하면 운영 체제도 암호화되어 시스템이 시작될 때 실행할 수 없기 때문입니다. 따라서 하드웨어는 디스크 내용이 암호화되어 있고 요청된 디스크 블록을 운영 체제로 전달할 때 즉시 암호 해독을 수행해야 한다는 것을 이해해야 합니다. 이러한 추가 작업이 수행되기 때문에 전체 디스크 암호화로 인해 읽기/쓰기 속도가 느려지므로 이러한 시스템 개발자는 이를 염두에 두어야 합니다.
종단 간 암호화
요즘 대규모 소셜 네트워크의 개인 정보 보호 및 보안 악몽이 계속되고 있어 앱을 만들거나 유지 관리하는 것과 관련이 없더라도 “종단 간 암호화”라는 용어를 모르는 사람은 없습니다.
앞에서 전체 디스크 암호화가 어떻게 궁극적인 방탄 전략을 제공하는지 보았지만 일반 사용자에게는 편리하지 않습니다. 내 말은, Facebook이 생성하고 휴대폰에 저장하는 전화 데이터가 안전하기를 원하지만 전체 전화를 암호화하고 그 과정에서 다른 모든 것을 잠글 수는 없다고 상상해보십시오.
이러한 이유로 이러한 회사는 엔드투엔드 암호화를 시작했습니다. 즉, 앱에서 생성, 저장 또는 전송할 때 데이터가 암호화됩니다. 즉, 데이터가 수신자에게 도달하더라도 완전히 암호화되어 수신자의 전화로만 액세스할 수 있습니다.
이미지 크레디트: 구글
E2E(End-to-End) 암호화는 공개 키 암호화와 같은 수학적 보장을 제공하지 않습니다. 키가 비즈니스와 함께 저장되는 표준 암호화일 뿐이며 메시지는 비즈니스가 결정하는 대로 안전합니다.
결론 👩🏫
대부분의 용어에 대해 이미 들어 보셨을 것입니다. 어쩌면 그들 모두일 수도 있습니다. 그렇다면 이러한 개념에 대한 이해를 다시 검토하고 해당 개념을 얼마나 진지하게 받아들이는지 평가해 보시기 바랍니다. 앱 데이터 보안은 단 한 번이 아니라 매번 승리해야 하는 전쟁이라는 점을 기억하세요. 단 한 번의 위반으로도 전체 산업, 경력, 심지어 생명까지 파괴할 수 있기 때문입니다!