251203 TIL (실시간 데이터 처리 - Jwt 인증 구현)

❗어떤 문제가 있었는지

실시간 데이터 처리 강의 실습을 따라가며 강의에서 진행한 MySQL 생성 및 연결 방식과 강의와의 연결방식이 달랐다.

• 내가 진행하는 방식 : Docker를 활용한 컨테이너 생성 및 IntelliJ DB 연결
• 강의에서 진행하는 방식 : MySQL Workbench를 활용한 DB 생성 및 연결

---

📝  내가 시도해본 것들

• 현재 내 로컬 기준으로는 Docker가 깔려있는 상태이므로 터미널을 통해 필요한 가상의 MySQL 서버를 구축했다.

docker run --name 컨테이너명 \
  -e MYSQL_ROOT_PASSWORD=비밀번호 \
  -e MYSQL_DATABASE=DB명 \
  -p 3306:3306 \ // 연결이 필요한 포트
  -d mysql:8.0 // 필요한 버전

• 이후 Docker로 생성되고 실행된 mysql을 통해 실습 중이었던 IntelliJ에서 규칙에 맞춰 DB를 적용시켜 연결시키는 과정으로 접근하고자 했다.

---

💡 어떻게 해결했는지

• 사실 동작하는 개념은 모두 같은 곳을 바라보고 있다는 점이었다. 
  • Docker 터미널로 접근을 하여 MySQL 사용자를 생성하거나,
  • IntelliJ를 통해 DB 연결 이후 콘솔을 통해 사용자를 생성하는 과정

→ Docker hub를 통해 필요한 MySQL 버전을 확인하고 Docker image로 받는다.

 

MySQL Docker 컨테이너 생성 및 실행

$ docker run --name mysql-container -e MYSQL_ROOT_PASSWORD=<password> -d -p 3306:3306 mysql:latest

 

실행 이후 원하던 대로 잘 구성되었는지 확인하기 위해 실행중인 컨테이너 리스트를 확인하고

$ docker ps -a

 

MySQL Docker 컨테이너에 접속할 수 있다.

$ docker exec -it chat-mysql mysql -u chatuser -p

Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 232
Server version: 8.0.44 MySQL Community Server - GPL

Copyright (c) 2000, 2025, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

 

접속 이후 MySQL 유저 생성을 진행할 수 있고

CREATE USER '아이디'@'%' IDENTIFIED BY '비밀번호';

 

생성한 유저에 대해 권한을 설정할 수 있다.

GRANT ALL PRIVILEGES
    ON {DB_NAME}.*
    TO {아이디}@localhost;

 

최종 권한 부여시에는 다음과 같이 진행할 수 있다.

FLUSH PRIVILEGES;

---

👍 무엇을 새롭게 알았는지

• 해당 접근방식을 알게된 부분은 root 계정이 아닌 유저 생성을 통한 권한 부여를 진행하는 이유에 대해서 알게 되었다.
  
  

root 계정 대신 별도로 생성한 계정을 사용하는 주된 이유

• 보안 강화
  • 최소 권한의 원칙 : root 계정은 데이터베이스 서버에 대한 모든 권한(슈퍼 유저 권한)을 가지고 있습니다. 이 계정이 유출되면 데이터베이스 전체가 심각한 보안 위협에 노출됩니다. 반면, 일반 계정은 애플리케이션 운영에 필요한 최소한의 권한(예: 특정 DB의 SELECT, INSERT, UPDATE, DELETE)만 부여받습니다. 이를 통해 계정이 유출되더라도 피해 범위를 최소화할 수 있습니다.
  • 공격 표면 감소: 많은 시스템에서 기본적으로 사용되는 root와 같은 계정 이름은 해커의 무차별 대입 공격(Brute Force Attack) 대상이 되기 쉽습니다. 고유한 사용자 이름을 사용하면 이러한 공격의 성공 가능성을 줄일 수 있습니다.
• 권한 관리 및 추적 용이성 
  • 책임 추적성 (Accountability): root 계정은 여러 개발자나 관리자가 공유하는 경우가 많습니다. 특정 시점에 어떤 사용자가 어떤 변경을 일으켰는지 추적하기 어렵습니다. 사용자별로 고유한 계정을 사용하면 누가 어떤 작업을 수행했는지 명확하게 기록하고 추적할 수 있습니다.
  • 세분화된 권한 제어: 운영(Production), 개발(Development), 테스트(Testing) 환경별로, 또는 팀원별로 필요한 권한을 정확하게 설정할 수 있습니다. 예를 들어, 운영 환경 데이터베이스에는 읽기 권한만 부여하고, 개발 환경에서는 모든 권한을 부여하는 식의 세밀한 관리가 가능합니다.

이를 통해 root 계정은 데이터베이스 시스템 관리 목적의 사용을 진행하고, 실제 애플리케이션 운영 및 개발 작업 시에는 목적에 맞게 권한이 제한된 별도 계정을 사용하는 것이 필요하다는 점을 알게 되었다.