고민의 흔적

TDE

TDE(Transparent Data Encryption)는 특정 데이터 영역을 암호화하는 것이다. 크게 보면 두가지로 테이블 스페이스를 통해 특정 데이터 공간을 암호화 하거나 테이블의 특정 칼럼만 암호화 할 수 있다.

TDE에서 사용하는 암호화 알고리즘

1. 3DES168
2. AES128
3. AES198
4. AES256

가능하면 AES256을 사용하는 것을 추천한다. WALLET 암호화 파일 생성이 완료되면 USB에 따로 저장하고 WALLET 만들 때 사용했던 암호는 꼭 보관하거나 기억해야한다.

WALLET 디렉터리 생성

cd $ORACLE_BASE
cd /oracle/app/oracle

mkdir /oracle/app/oracle/wallet

sqlnet.ora파일에 내용 추가

cd $ORACLE_HOME/network/admin
cd /oracle/app/oracle/product/19.0.0.0/db_1/network/admin

-- sqlnet.ora 파일 백업
cp sqlnet.ora sqlnet.ora_20221215

vi sqlnet.ora

ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA= (DIRECTORY=/oracle/app/oracle/wallet)))

WALLET Key 생성 및 AUTO LOGIN 설정

cd /oracle/app/oracle/wallet

-- sqlplus / as sysdba 접속
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/oracle/app/oracle/wallet' IDENTIFIED BY oracle123;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY oracle123;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY oracle123 WITH BACKUP;
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/oracle/app/oracle/wallet' IDENTIFIED BY oracle123;

Oracle TDE 테이블스페이스 생성

-- AES 128 테이블스페이스 생성
CREATE TABLESPACE TS_STRS_D
DATAFILE '/oracle/app/oracle/oradata/STRP/TS_STRS_D_001.DBF' SIZE 2048M
ENCRYPTION USING 'AES128'
DEFAULT STORAGE (ENCRYPT);

-- AES 256 테이블스페이스 생성
CREATE TABLESPACE TS_STRE_D
DATAFILE '/oracle/app/oracle/oradata/STRP/TS_STRE_D_001.DBF' SIZE 2048M
ENCRYPTION USING 'AES256'
DEFAULT STORAGE (ENCRYPT);

-- TDE 생성 확인
SELECT
    A.NAME, 
    B.ENCRYPTIONALG,
    C.NAME,
    C.BYTES/1024/1024 AS "SIZE(MB)"
FROM 
    V$TABLESPACE A,
    V$ENCRYPTED_TABLESPACES B,
    V$DATAFILE C
WHERE A.TS# = B.TS#
AND   A.TS# = C.TS#
ORDER BY 1,2;

테이블 특정 칼럼 암호화(ENCRYPT AES256)

CREATE TABLE SYSTEM.TDE_TEST4
(
    T_NAME	VARCHAR2(500),
    T_KEY		VARCHAR2(500),
    T_MOB		VARCHAR2(100)	ENCRYPT USING 'AES256',
    T_ADR		VARCHAR2(2000)	ENCRYPT USING 'AES256'
)
TABLESPACE SYSAUX;

Tips.

TDE의 암호화된 공간은 테이블의 데이터만 넣어주어야 한다. 암호화되면 DB성능에 영향이 있기 때문에 테이블만 넣고 인덱스는 일반 테이블 스페이스 공간에 넣어주어야 문제 없이 사용이 가능하다. 개인 정보가 있는 중요한 데이터만 넣고 테이블의 데이터가 너무 크면 특정 칼럼만 암호화해서 사용하는게 좋다.

참고

https://www.youtube.com/watch?v=u5ReY3qi9Lg 

개요

기존에 Jasypt 패키지를 이용해 YML 설정 파일 암호화를 진행하였지만 application.yml 파일 내 jasypt.encryptor.password가 노출되어있어 암호화는 해주었지만 암호화를 풀 수 있는 열쇠를 노출해 이와 같은 문제를 해결하는 방법으로 Github Repository secrets을 이용해 해결하였습니다.

떠오른 방법

1. 암호화를 풀 수 있는 키를 우분투 서버 자체에 환경변수로 등록하여서 도커 컨테이너에 스프링 run 할 때 환경변수를 전달한다.
2. Github Repository secrets를 이용한다.
3. Spring Vault를 이용한다.

Spring Vault란?

Vault는 HashiCorp에 의해서 개발된 크로스 플랫폼 패스워드 및 인증 관리 시스템이다. 공개되면 안 되는 비밀번호, API 키, 토큰 등을 저장하고 관리한다.

선택한 방법

우선 저는 제일 간단한 방법으로 진행하기 위해 2번을 선택했습니다.

시간이 되면 1번 방법과 3번 방법으로 진행해 보겠습니다.

해결 방법

1. GitHub 해당 Repository에 들어가서 Settings에서 왼쪽 하단에 있는 Secrets의 Actions에 접속한다.

2. Secrets의 Actions에서 오른쪽 상단에 있는 New repository secret을 선택한다.

3. secret의 Name을 입력하고 Secret에는 암호화를 진행하고 싶은 내용을 입력하고 Add secret을 누르면 생성된다.

4. 현재 제가 만든 secret 목록입니다.

5. .github/workflows/gradle.yml 파일에 아래의 코드를 추가한다.

Repository secrets을 사용하면 GitHub Actions의 gradle.yml에만 환경변수가 적용되어 스프링에서 사용할 수 있게 변수를 넘겨주어야 한다.

- name: Set Yaml
  uses: microsoft/variable-substitution@v1
  with:
    files: ./src/main/resources/application-prod.yml 
  env:
    spring.datasource.url: ${{ secrets.DB_URL }} 
    spring.datasource.username: ${{ secrets.DB_USERNAME }} 
    spring.datasource.password: ${{ secrets.DB_PASSWORD }}

gradle.yml 전체 코드

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: <https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-gradle>
name: Java CI with Gradle

on:
  push:
    branches: [ "main" ]
#   pull_request:
#       branches: [ "main" ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    - name: Set Yaml
      uses: microsoft/variable-substitution@v1
      with:
        files: ./src/main/resources/application-prod.yml 
      env:
        spring.datasource.url: ${{ secrets.DB_URL }} 
        spring.datasource.username: ${{ secrets.DB_USERNAME }} 
        spring.datasource.password: ${{ secrets.DB_PASSWORD }} 
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build
    - name: Docker build
      run: |
       docker login -u ${{ secrets.USERNAME }} -p ${{ secrets.PASSWORD }}
       docker build -t spring-cicd2 .
       docker tag spring-cicd2 lusida0131/spring-cicd2:latest
       docker push lusida0131/spring-cicd2:latest
  deploy:
    needs: build  # build 후에 실행되도록 정의
    name: Deploy
    runs-on: [ self-hosted, label-go ] # AWS ./configure에서 사용할 label명
    steps:
      # 3000 -> 80 포트로 수행하도록 지정
      - name: Docker run
        run: |
          docker login -u ${{ secrets.USERNAME }} -p ${{ secrets.PASSWORD }}
          docker stop spring-cicd2 && docker rm spring-cicd2 && docker rmi lusida0131/spring-cicd2:latest
          docker run -d -p 8081:8081 --name spring-cicd2 --restart always lusida0131/spring-cicd2:latest

변수는 ${{ secrets.적용한이름 }}으로 불러올 수 있다. 위의 코드를 보면 ./src/main/resources/application-prod.yml의 파일에 spring.datasource.url를 ${{ secrets.DB_URL }} 변수로 덮어 씌운다. 실제 application-prod.yml의 값은 임의의 값을 주어도 상관없다.

datasource:
    url: ${url}
    username: ${username}
    password: ${password}

개요

GitHub의 프로젝트 레파지토리에 application.yml이나 application.properties 파일에 DB의 유저 정보와 비밀번호 또는 키값을 명시해두는 경우가 있습니다. 또한 yml이나 properties을. gitignore에 추가할 경우 aws에서 프로젝트를 실행하는 경우나 docker로 실행하는 경우 이와 같은 오류가 발생한다. "Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured. Reason: Failed to determine a suitable driver class” 위의 오류는 database 설정 파일을 찾지 못해서 나는 오류이다. 하지만 DB 정보를 명시해두는 경우 GitHub 특성상 오픈 소스이므로 정보가 노출되어 보안에 심각한 문제를 초래할 수 있다는 점입니다. 위와 같은 사항들을 해결하기 위해 보안에 민감한 값들을 암호화시켜 저장해야 한다.

암호화 방식

YML파일 암호화 방법으로는 여러 방법이 있지만 저는 Java의 Jasypt(Java Simplified Encryption) 패키지를 사용하여 설정 파일들의 암호화를 진행하겠습니다.

장점

Jasypt를 설정하려면 여러 코드들이 추가되지만 로컬,배포 환경의 설정 파일을 동일하게 사용할 수 있고 설정 파일이 외부 유출되어도 암호화되어있기에 비교적 안전하다는 장점이 있다.

암호화 진행 순서

1. build.gradle파일에 jasypt implementation을 작성한다.

// yml 설정 파일 암호화
implementation 'com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.3'

2. jasyptStringEncryptor로 Bean을 등록합니다. 이 이름은 application.yml의 jasypt bean으로 등록할 때 사용합니다. private String PASSWORD는 yml 설정 파일에서 jasypt.encryptor.password으로 읽어서 가져옵니다.

import org.jasypt.encryption.StringEncryptor;
import org.jasypt.encryption.pbe.PooledPBEStringEncryptor;
import org.jasypt.encryption.pbe.config.SimpleStringPBEConfig;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class JasyptConfig {

		@Value("${jasypt.encryptor.password}")
    private String PASSWORD;

    @Bean(name = "jasyptStringEncryptor")
    public StringEncryptor stringEncryptor() {
        PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
        SimpleStringPBEConfig config = new SimpleStringPBEConfig();
        config.setPassword(PASSWORD); // 암호화할 때 사용하는 키
        config.setAlgorithm("PBEWithMD5AndDES"); // 암호화 알고리즘
        config.setKeyObtentionIterations("1000"); // 반복할 해싱 회수
        config.setPoolSize("1"); // 인스턴스 pool
        config.setProviderName("SunJCE");
        config.setSaltGeneratorClassName("org.jasypt.salt.RandomSaltGenerator"); // salt 생성 클래스
        config.setStringOutputType("base64"); //인코딩 방식
        encryptor.setConfig(config);
        return encryptor;
    }
}

3. application.yml에 암호화된 값을 적어주기 전에 미리 해당 값들의 암호화된 값을 알기위해 Test코드를 작성해서 출력한다.

import org.assertj.core.api.Assertions;
import org.jasypt.encryption.pbe.StandardPBEStringEncryptor;
import org.junit.jupiter.api.Test;

class JasyptConfigTest {

    @Test
    void jasypt(){
        String url = "자신의 DB URL";
        String username = "자신의 DB USER";
        String password = "자신의 DB PASSWORD";

        String encryptUrl = jasyptEncrypt(url);
        String encryptUsername = jasyptEncrypt(username);
        String encryptPassword = jasyptEncrypt(password);

        System.out.println("encryptUrl : " + encryptUrl);
        System.out.println("encryptUsername : " + encryptUsername);
        System.out.println("encryptPassword : " + encryptPassword);

        Assertions.assertThat(url).isEqualTo(jasyptDecryt(encryptUrl));
    }

    private String jasyptEncrypt(String input) {
        String key = "암호화에 쓰일 키값";
        StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
        encryptor.setAlgorithm("PBEWithMD5AndDES");
        encryptor.setPassword(key);
        return encryptor.encrypt(input);
    }

    private String jasyptDecryt(String input){
        String key = "복호화에 쓰일 키값";
        StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
        encryptor.setAlgorithm("PBEWithMD5AndDES");
        encryptor.setPassword(key);
        return encryptor.decrypt(input);
    }
}

4. 위의 TestCode를 작성하면 암호화된 값이 출력된다.

5. application.yml에 암호화된 값과 jasyptStringEncryptor bean 설정

spring:
  datasource:
    url: ENC(o9FcC1LtWYlFw88yy/5Ilg==)
    username: ENC(cp/1/Ok8sPGkYEJi27Jknw==)
    password: ENC(9vlmkROOsAgMTk3rFkbiQxXFwFaQoew0)
jasypt:
  encryptor:
    bean: jasyptStringEncryptor
    password : 1234

jasyptStringEncryptor를 jasypt bean으로 등록하고, 각 속성값에 ENC( 암호화 값 ) 형식으로 입력해줍니다. 위와 같은 과정을 통해 application.yml 파일의 암호화를 설정해 주었습니다. 하지만, application.yml 파일 내 jasypt.encryptor.password가 노출되어있다면, 암호화는 해주었지만 암호화를 풀 수 있는 열쇠를 지어준 꼴이 된다. 이와 같은 문제를 해결하는 방법은 다음에 작성해 보겠습니다.

HTTP/1.0

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어있다. 서버로부터 파일을 가져올 때마다 TCP의 3-way-handshake를 계속해서 열어야 하기 때문에 RTT가 증가하는 단점이 있다.

RTT

패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간, 패킷 왕복 시간

RTT 증가를 해결하기 위한 방법

매번 연결할 때마다 RTT가 증가하니 서버에 부담이 많이 가고 사용자 응답 시간이 길어졌다. 이를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용했다.

이미지 스플리팅

많은 이미지를 다운로드하게 되면 과부하가 걸리기 때문에 많은 이미지가 협쳐 있는 하나 이미지를 다운로드하고, 이를 기반으로 background-image의 position을 이용해 이미지를 표기하는 방법이다.

코드 압축

코드압축은 코드를 압축해 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법이다.

개행 문자, 띄어쓰기 등이 사라져 코드가 압축되면 코드 용량이 줄어든다.

이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법이다. 이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있다. 하지만 Base64 문자열로 변환할 경우 37% 정도 크기가 더 커지는 단점이 있다.

HTTP/1.1

매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다. 한번 TCP 3-way-shake 가 발생하면 그다음부터 발생하지 않는 것을 볼 수 있다. 하지만 문서 안에 포함된 다수의 리소스(이미지, css, script)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다.

HOL Blocking

HOL Blocking은 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상이다. 예를 들어 image.jpg와 style.css, data.xml을 다운로드받을 때 보통은 순차적으로 잘 받아지지만 image.jpg가 느리게 받아진다면 그 뒤에 있는 것들이 대기하게 되며 다운로드가 지연되는 상태가 된다.

무거운 헤더 구조

HTTP/1.1의 헤더에는 쿠키등 많은 메타데이터가 들어 있고 압축이 되지 않아 무거웠다.

HTTP/2.0

HTTP/2.0은 HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위를 처리를 지원하는 프로토콜이다.

멀티플렉싱

멀티플렉싱이란 여러 개의 스트림을 사용하여 송수신한다는 것이다. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있다. 멀티플렉싱을 통해 단일 연결을 사용하여 병렬로 여러 요청을 받을 수 있고 응답을 줄 수 있다. 이렇게 되면 HTTP/1.x에서 발생하는 HOL Blocking을 해결할 수 있다.

스트림

시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

헤더 압축

HTTP/1.x에서 크기가 큰 헤더의 문제를 HTTP/2.0에서는 헤더 압축을 써서 해결하는데, 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가진다.

허프만 코딩

문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트 양을 줄이는 원리이다.

서버 푸시

HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운받을 수 있었다면, HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.

HTTPS

HTTP/2는 HTTPS 위에서 동작한다. HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청이다.

SSL/TLS

SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜이다. 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제삼자가 메시지를 도청하거나 변조하지 못하도록 한다. SSL/TLS를 통해 공격자가 서비인 척하며 사용자 정보를 가로채는 네트워크 상의 인터셉터를 방지할 수 있다.

SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다. 참고로 TLS 1.3은 사용자가 이전에 방문한 사이트로 다시 방문한다면 SSL/TLS에서 보안 세션을 만들 때 걸리는 통신을 하지 않아도 된다. 이를 0-RTT라 한다.

보안 세션

보안 세션이란 보안이 시작되고 끝나는 동안 유지되는 세션을 말하고, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다. 클라이언트와 서버와 키를 공유하고 이를 기반으로 인증, 인증 확인 등의 작업이 일어나는 단 한 번의 1-RTT가 생긴 후 데이터를 송수신하는 것을 볼 수 있다. 클라이언트에서 사이퍼 슈트를 서버에 전달하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인한다. 제공할 수 있다면 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작되고 이후 해싱 알고리즘 등으로 암호화된 데이터의 송수신이 시작된다.

사이퍼 슈트

사이퍼 슈트는 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약을 말하며 다섯 개가 있다.

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

TLS_AES_128_GCM_SHA256에는 세가지 규약이 들어 있는데 TLS는 프로토콜, AES_128_GCM은 AEAD 사이퍼 모드, SHA256은 해싱 알고리즘을 뜻한다.

AEAD 사이퍼 모드

AEAD는 데이터 암호화 알고리즘이며 AES_128_GCM 등이 있다. 예를 들어 AES_128_GCM이라는 것은 128비트의 키를 사용하는 표준 블록 함호화 기술과 병렬 계산에 용이한 암호화 알고리즘 GCM이 결합된 알고리즘을 뜻한다.

암호화 알고리즘

키 교환 암호화 알고리즘으로는 대수곡선 기반의 ECDHE 또는 모듈식 기반의 DHE를 사용한다. 둘 다 디피-헬만 방식을 근간으로 만들어졌다.

디피-헬만 키 교환 암호화 알고리즘

디피-헬만 키 교환 암호화 알고리즘은 암호키를 교환하는 하나의 방법이다.

처음에 공개 값을 공유하고 각자의 비밀 값과 혼합한 후 혼합 값을 공유한다. 각자 비밀 값과 또 혼합한다. 그 이후에 공통의 암호키가 생성되는 것이다.

SHA-256 알고리즘

SHA-256 알고리즘은 해시 함수의 결괏값이 256비트인 알고리즘이며 해싱을 해야 할 메세지에 1을 추가하는 등 전처리를 하고 전 처리된 메시지를 기반으로 해시를 반환한다.

HTTPS 구축 방법

직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스를 구축하거나, 서버 앞단의 HTTPS를 제공하는 로드밸런서를 두거나, 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축한다.

HTTP/3

TCP 위에서 돌아가는 HTTP/2와는 달리 HTTP/3은 QUIC이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.

QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way-handshake과정을 거치지 않아도 된다. QUIC는 첫 연결 설정에 1-RTT만 소요된다. QUIC는 순방향 오류 수정 메커니즘이 적용되었다. 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.