암호화는 보안과 관련된 주제인 경우가 많지만 개인 정보 보호에서도 중요합니다. 암호화의 목표는 다른 사람이 암호화된 정보를 읽지 못하게 하는 것이지만 다른 사람이 사용자의 정보를 읽지 못하도록 하는 것은 정보를 비공개로 유지하는 한 가지 방법입니다. 사용자가 직접 수행할 수 있는 작업은 제한되어 있는 경우가 많지만, 사용자가 사용 중인 서비스의 제공자인 사용자의 도움을 받으면 암호화를 통해 사용자의 데이터를 유지할 수 있습니다.
사용자 개인 정보 보호를 위해 암호화를 적용하는 방법에는 전송 중 암호화, 저장 데이터 암호화, 엔드 투 엔드 암호화 등 세 가지가 있습니다.
- 전송 중 암호화는 사용자와 사이트(즉, HTTPS) 간의 데이터 암호화를 유지합니다. 이미 사이트에 HTTPS를 설정했을 수 있지만, 사이트로 전송되는 모든 데이터가 암호화되고 있을까요? 리디렉션과 HSTS는 이러한 용도이며, 아래에 설명되어 있으며 HTTPS 설정의 일부여야 합니다.
- 저장 데이터 암호화는 서버에 저장된 데이터의 암호화입니다. 이는 정보 유출로부터 보호하며 보안 입장에서 중요한 부분입니다.
- 엔드 투 엔드 암호화는 클라이언트 데이터가 서버에 도달하기 전에 데이터를 암호화하는 것입니다. 이렇게 하면 개발자에게도 사용자 데이터가 보호됩니다. 사용자의 데이터를 저장할 수는 있지만 읽을 수는 없습니다. 이 방법은 구현하기 어렵고 모든 유형의 애플리케이션에 적합하지는 않지만, 본인 이외의 다른 데이터는 볼 수 없으므로 사용자 개인 정보 보호에 큰 도움이 됩니다.
HTTPS
첫 번째 이동은 HTTPS를 통해 웹 서비스를 제공하는 것입니다. 이 작업을 이미 완료했을 가능성이 매우 높지만 그렇지 않다면 중요한 단계입니다. HTTPS는 브라우저가 서버에서 웹페이지를 요청하는 데 사용하는 프로토콜인 HTTP이지만 SSL을 사용하여 암호화됩니다. 즉, 발신자 (사용자)와 수신자 (귀하) 간의 HTTPS 요청은 외부 공격자가 읽거나 방해할 수 없습니다. HTTPS 요청이 암호화되어 있으므로 읽거나 변경할 수 없기 때문입니다. 즉, 데이터가 사용자에게서 사용자에게 또는 사용자에게서 사용자에게 이동하는 동안 전송 중 암호화입니다. 또한 전송 중 HTTPS 암호화를 사용하면 사용자의 ISP 또는 사용자가 사용 중인 Wi-Fi 제공업체가 서비스와의 관계의 일환으로 사용자에게 보내는 데이터를 읽을 수 없습니다. 이는 서비스 기능에도 영향을 미칠 수 있습니다. 기존 JavaScript API를 사용할 경우 HTTPS를 통해 웹사이트를 제공해야 하는 경우가 많습니다. MDN에는 좀 더 포괄적인 목록이 있지만, 안전한 컨텍스트로 구동되는 API에는 서비스 워커, 푸시 알림, 웹 공유 및 웹 암호화, 일부 기기 API가 포함됩니다.
HTTPS를 통해 웹사이트를 제공하려면 SSL 인증서가 필요합니다. 이러한 파일은 Let's Encrypt를 통해 무료로 생성하거나 호스팅 서비스를 사용하는 경우 호스팅 서비스에서 제공할 수도 있습니다. 웹 서비스를 '프록시'하고 HTTPS는 물론 캐싱 및 CDN 서비스도 제공하는 서드 파티 서비스를 사용할 수도 있습니다. Cloudflare, Fastly 등 그와 같은 서비스의 수많은 예시가 있으며, 정확히 어떤 서비스를 사용해야 할지는 현재 인프라에 따라 달라집니다. 과거에는 HTTPS를 구현하는 데 부담이 되거나 비용이 많이 들 수 있었기 때문에 결제 페이지나 특히 안전한 출처에서만 HTTPS를 사용했었습니다. 하지만 무료로 제공되는 인증서, 표준 개선, 더 많은 브라우저 확산 덕분에 이러한 모든 장애물이 해결되었습니다.
의견을 제시하지
- 모든 경우에 (선택한 방법) 서버에서 HTTPS를 사용 설정합니다.
- Cloudflare와 같은 서버 앞에 프록시를 사용하는 것이 좋습니다. httpsiseasy.com/에서 자세히 알아보세요.
- Let's Encrypt는 자체 Let's Encrypt SSL 인증서를 만드는 과정을 안내합니다.
- 또는 OpenSSL을 직접 사용하여 자체 인증서를 만들어 원하는 인증 기관(CA)에서 서명하도록 합니다. HTTPS 사용 설정에서 자세한 방법을 확인할 수 있습니다.
비즈니스 장단점에 따라 접근 방식을 선택해야 합니다. 제3자가 SSL 연결을 관리하도록 하면 가장 쉽게 설정할 수 있으며 부하 분산, 캐싱, 분석과 같은 다른 이점이 있습니다. 하지만 그로 인해 제3자에게 제어 권한이 어느 정도 양도되고 제3자의 서비스에 대한 불가피한 의존이 발생하게 됩니다 (사용 중인 서비스와 트래픽 수준에 따라 결제 가능)
이전에는 인증서를 생성하고 CA에서 서명하도록 하는 것이 SSL 프로세스가 실행되었던 방식이지만, 제공업체가 지원하거나 서버 팀이 기술적으로 이를 충분히 능숙하게 사용할 수 있고 무료인 경우 Let's Encrypt를 사용하는 것이 더 쉬울 수 있습니다. 클라우드 호스팅보다 상위 수준의 항목을 사용하는 경우 제공업체가 서비스로 SSL을 제공하는 경우도 많으므로 확인해 볼 필요가 있습니다.
이유
보안은 개인 정보 보호 스토리의 일부입니다. 간섭으로부터 사용자 데이터를 안전하게 보호한다는 것을 입증하면 신뢰를 구축하는 데 도움이 됩니다. HTTPS를 사용하지 않으면 브라우저에 의해 사이트가 '안전하지 않은' 것으로 신고되며 한동안 문제가 지속됩니다. 기존 JavaScript API는 HTTPS 페이지 ('보안 출처')에서만 사용할 수 있는 경우가 많습니다. 또한 사용자의 웹 사용 시 ISP에 노출되지 않도록 사용자를 보호합니다. 이는 확실히 권장사항입니다. 현재 웹사이트에 HTTPS를 사용하지 않을 이유가 거의 없습니다.