CORS를 흉내낸, 백엔드 서버간 통신 방법

들어가며

안녕하세요. 노머스에서 백엔드 개발을 하고 있는 유영기입니다.

회사가 성장하면서 트래픽이 증가되어, 도메인별로 서비스가 분화될 수 밖에 없고, 그에 따라 서버간 통신도 빈번해 졌습니다.
기존에는 자체 생성 메타 정보를 가지고, AES-256 암호화를 통해 서버간 통신을 했는데, 성능 프로파일링 과정에서 높은 CPU 사용률을 확인하였습니다.
서버간의 인증을 위해, CORS에서 힌트를 얻어 내부 서버간의 통신에 적용한 방법과 개선 결과를 공유하고자 합니다.

개발

프로젝트 배경

조직이 커지고, infra가 많아지면서 interface 관점에서 저희는 gRPC를 고민해 본 적이 있습니다.
그 과정에서 성능 프로파일링을 몇번 하게되었고, 그 과정에서 기존에 서버 내부간 인증으로 사용하고 있던 AES-256 암호화 방식의 높은 CPU 사용률과 이로 인한 느린 response time을 확인하게 되었습니다.

개선해야겠다고 생각하고 있던 와중에, 우리가 쉽게 접하고 있는 CORS에서 힌트를 얻어, 이를 서버간 통신에 적용해 보았습니다.
성능적 개선도 해야겠지만, 서버간 통신이 많아지면서 점점 늘어나는 내부 인증용 메타 정보, AES-256 코드도, 새 방식에서는 package로 만들어 서버간 통신의 쉬운 사용도 관심사 였습니다.

Coding Theory

Coding Theory에 나오는 종류를 간단히 정리해 보겠습니다.

• Source coding (Data compression)
  • Lossless
    • ZIP
  • Lossy
    • MP3, MPEG, JPEG
• Channel coding (Error control)
  • Viterbi Decoder
  • Turbo Coding
• Cryptographic coding (Encryption)
  • 양방향
    • 대칭키
      • AES-256
    • 비대칭키
      • RSA
  • 단방향 (Hash)
    • SHA-256
• Line coding

monorepo package

monorepo와 nestjs를 사용하고 있어, package에 만들었습니다.

@Module({
    imports: [ConfigModule],
    providers: [InternalOriginGuard, InternalAxiosService],
    exports: [InternalOriginGuard, InternalAxiosService]
})
export class InternalApiModule {}

서버간 통신이라 할지라도, client-server 관계는 존재하는데,
InternalAxiosService는 client용이고, InternalOriginGuard는 server용이지만,
서버간 통신에서 영원히 client 역할로, 혹은 server 역할로 규정할 수 없기 때문에, 이 둘을 묶어 module로 만들었습니다.

백엔드의 각 서버는 자신의 API domain 값을 origin 환경변수로 추가합니다.
이 origin 값과, HMAC의 signature는 InternalAxiosService를 사용하면 자동으로 붙어 나가게 하였습니다.

InternalAxiosService

internal client용 axios instance를 만들어, origin과 signature를 붙여 보내게 하였습니다.

@Injectable()
export class InternalAxiosService {
  readonly #axiosInstance: AxiosInstance;

  constructor(private readonly configService: ConfigService) {
    const secretKey = this.configService.getOrThrow('INTERNAL_API_SECRET_KEY'); 
    const origin = this.configService.getOrThrow('INTERNAL_API_ORIGIN');

    this.#axiosInstance = axios.create();
    this.#axiosInstance.interceptors.request.use(config => {
      config.headers['origin'] = origin;
      config.headers['x-signature'] = crypto.createHmac('sha256', secretKey).update(origin).digest('hex');
      return config;
    });
  }

  get instance(): AxiosInstance {
    return this.#axiosInstance;
  }
}

InternalOriginGuard

internal server용 guard를 만들어, origin과 signature를 확인하게 하였습니다.

@Injectable()
export class InternalOriginGuard implements CanActivate {
  readonly #INTERNAL_API_SECRET_KEY: string;
  readonly #INTERNAL_API_ALLOWS: string[];

  constructor(private readonly configService: ConfigService) {
    this.#INTERNAL_API_SECRET_KEY = this.configService.getOrThrow('INTERNAL_API_SECRET_KEY');
    this.#INTERNAL_API_ALLOWS = this.configService.getOrThrow('INTERNAL_API_ALLOWS');
  }

  canActivate(context: ExecutionContext): boolean {
    const request: Request = context.switchToHttp().getRequest();

    const origin = request.headers['origin'] as string;
    const signature = request.headers['x-signature'] as string;

    if (!origin || !signature) {
      throw new UnauthorizedException('Missing origin or signature');
    }

    const expectedSignature = crypto.createHmac('sha256', this.#INTERNAL_API_SECRET_KEY).update(origin).digest('hex');

    if (signature !== expectedSignature) {
      throw new UnauthorizedException('Invalid signature');
    }

    if (!this.#INTERNAL_API_ALLOWS.include(origin)) {
      throw new UnauthorizedException('Invalid origin');
    }

    return true;
  }
}

1. header에 origin과 signature가 있는지 확인합니다.
2. 서버에서도 가지고 있는 secretKey로 signature를 만들어, header의 signature와 비교합니다.
3. 각 서버에서 가지고 있는 allowed origin list에 포함되어 있는지 확인합니다.

적용

도메인마다 여러 서버가 존재하지만, 특히 서버간 통신이 많은 membership server에 적용하였습니다.
얼마전 membership server를 내부적으로 호출하는 모든 client(internal interface 관점에서 client이지만 백엔드 서버입니다.)에 새로운 방식의 통신방식을 적용하고 나온 lambda 서버의 변화 입니다.

마치며

데이터 원문(plaintext)이 노출되면 안되는 영역과, 데이터의 무결성(Integrity)을 기대하는 영역에 따라 적절한 암호화 방식을 선택해야 합니다.

개선 및 기대 결과로는

• monorepo package에서 제공하는 InternalAxiosService를 사용하면 브라우저처럼 자동으로 origin을 붙여주어, 백엔드 로직 구현에 집중할 수 있게 되었고,
• 서버간 통신에서도 request의 origin을 알 수 있어, 디버깅시 추가적인 도구가 생겼습니다.
• lambda의 duration 개선으로 비용 절감도 기대됩니다.

감사합니다.