사용자 민감 정보 다루기 (with. TextEncryptor)

이번 글에서는 웹 API 통신에서 실제 사용자의 민감 정보를 다루어 본 경험에 대해 소개해보고자 합니다.

 

여느 때처럼 개발 중인 개발자 K 씨에게 PM팀의 요구사항이 도착합니다.

 

모든 고객이 서로의 Email을 입력하여 특정한 메세지를 보낼 수 있도록 해주세요

 

이 요구사항에는 심각한 고민거리가 있었습니다.

 

그것은 바로 

 

모든 고객은 실제 Email 주소를 사용한다는 것.

 

다시 말하면, 여기서 사용하고자 하는 Email 주소는 고객들이 실제 사용하는 gmail, naver와 같은 이메일 주소였던 것입니다.

 

Email 정보는 매우 민감한 개인 정보에 해당하기 때문에 외부에 그대로 노출 되어서는 안 되는 정보입니다.

 

PM팀으로부터 요청받은 세부 사항은 다음과 같습니다.

 

1. 모든 고객은 메세지를 보내기 전에 수신자로 입력한 Email이 실제로 데이터베이스에 존재하는 Email인지 확인할 수 있어야합니다.
2. 확인을 마친 고객은 복수개의 Email(고객) 에게 메세지를 전달할 수 있어야 합니다.

 

모든 고객은 수신 Email이 실제 존재하는지 검증하기 위해서 Email을 입력하여 검증에 해당하는 기능을 수행합니다.

 

고객의 요청은 Client를 타고 실제 Server로 들어와 해당 데이터가 존재하는지 확인하는 로직을 거친 후 

 

사용자에게 유효한 Email인 지 알려줘야 합니다.

고객 이메일 검증 과정

 

 

메세지를 보내고자 하는 수신자가 여러 명일 경우, 위 검증 로직을 N번 수행한 후, 고객은 메세지를 전송하게 됩니다.

메세지 전송 과정

 

고객의 민감 데이터인 Email을 Plain Text로 주고받을 경우 통신의 중간에서 악의적인 생각을 품은 누군가가 해당 데이터를 가로챌 경우, 이는 개인정보의 유출로 이어지게 됩니다.

 

개인정보 유출을 피하기 위해 한 가지 방법을 떠올리는데, 그것은 바로

 

Email 정보를 Hash 값으로 Encoding 하여 Client와의 통신에 사용할 것

 

 

위 사항을 구현하기 위해 Spring Security에 정의된 TextEncryptor 개념을 사용하기로 합니다.

public interface TextEncryptor {

	/**
	 * Encrypt the raw text string.
	 */
	String encrypt(String text);

	/**
	 * Decrypt the encrypted text string.
	 */
	String decrypt(String encryptedText);

}

 

 

TextEncryptor는 실제 Encrypt를 수행하는 기본 정의에 불과합니다.

 

 

따라서 TextEncryptor를 구현한 구현체인 KeyEncryptor를 새로 정의합니다.

public class KeyEncryptor implements TextEncryptor {
	private final Hashids hashids;
    
	@Override
	public String encrypt(String data) {
	    return hashids.encodeHex(Hex.encodeHexString(data.getBytes(StandardCharsets.UTF_8)));
	}
    
	@Override
	public String decrypt(String data) {
	    String decoded = hashids.decodeHex(data);
	}
}

 

KeyEncryptor는 TextEncryptor의 encrypt, decrypt 기능을 실체화 한 클래스로,

 

특정 Hash Key 값을 입력받아 데이터를 해당 Hash Key로 encrypt, decrypt 기능을 수행합니다.

 

 

개선 된 Email 검증 과정

 

개선 된 메세지 전송 과정

 

실제 비즈니스 로직에 해당하는 이메일 검증, 메세지 전송에 대한 역할 및 책임은 Server에 있고

 

Client는 단지 비즈니스 로직의 결과를 고객에게 전달만 하는 형태로 바뀌었습니다.

 

한마디로, Server에서 어떤 Key로 Email 정보를 암호화했는지 외부에서 알 필요가 없는 구조로 변경되면서,

 

Client는 이제 어떤 Email이 유효하고, 어떤 Email에게 메세지를 전송해야 하는가에 대해 궁금하지 않습니다.

 

Server로부터 응답받은 값을 그대로 사용하여 다시 Server로 전달할 뿐입니다.

 

 

마치며..

 

고객들의 개인정보를 다룰 때에는 항상 보안적인 부분에 대한 고민이 필요합니다.

 

위에서 살펴본 내용처럼, 보안적인 부분에 대한 대응책으로 

 

Spring에서 기본으로 제공하는 라이브러리의 구현체를 생성하여 활용하는 방법이 있습니다.

 

이 글이 개인정보에 대한 고민을 한 번 더 해보게 되는 계기가 되기를 바라며 마치겠습니다.