docs: Slack 권한 아이템화 방안으로 문서 업데이트
- Slack을 Gmail과 같은 권한 아이템으로 관리 - 웹에서 Slack OAuth 연결 시작 - slack_tokens 테이블로 매핑 관리 - 모든 채널 UUID로 통합하여 기억 일원화
This commit is contained in:
parent
e851a072d7
commit
5c888055e8
@ -1,10 +1,7 @@
|
||||
# JWT 인증 체계 보안 취약점 - CRITICAL
|
||||
# JWT 인증 체계 개선 - Slack 아이템화
|
||||
|
||||
## 작성일: 2025-08-27
|
||||
## 작성자: 51123 서버 관리자
|
||||
## 상태: 🔴 CRITICAL - 인증 우회 가능한 보안 취약점 발견
|
||||
## 영향 범위: 51124 전체 서비스 (rb10508_micro, skill-email, skill-news)
|
||||
## 위험 수준: 매우 높음
|
||||
## 상태: 해결 방안 제시 (2025-08-27)
|
||||
## 해결: Slack 권한 아이템 방식
|
||||
|
||||
---
|
||||
|
||||
@ -109,51 +106,40 @@ curl http://gateway:8100/api/stats/rb8001 \
|
||||
|
||||
---
|
||||
|
||||
## 5. 해결 방안
|
||||
## 5. 해결 방안: Slack 권한 아이템화
|
||||
|
||||
### 5.1 즉시 조치 (Phase 1)
|
||||
### 핵심 개념
|
||||
- Slack을 Gmail처럼 권한 아이템으로 관리
|
||||
- 웹에서 Slack OAuth 연결 시작
|
||||
- slack_tokens 테이블로 매핑 관리
|
||||
|
||||
#### 1. Slack 경로 JWT 추가 또는 분리
|
||||
```python
|
||||
# 옵션 1: Slack 이벤트에도 JWT 요구
|
||||
@app.post("/api/slack/events")
|
||||
async def slack_events(
|
||||
request: Request,
|
||||
auth: Optional[str] = Depends(verify_jwt_optional)
|
||||
):
|
||||
if not auth:
|
||||
# Slack 서명 검증로 대체
|
||||
verify_slack_signature(request)
|
||||
|
||||
# 옵션 2: Slack과 웹을 완전 분리
|
||||
# Slack 전용 서비스로 분리 고려
|
||||
### 구현 단계
|
||||
|
||||
#### 1. slack_tokens 테이블 생성
|
||||
```sql
|
||||
CREATE TABLE slack_tokens (
|
||||
user_id UUID NOT NULL,
|
||||
slack_user_id VARCHAR(100),
|
||||
slack_team_id VARCHAR(100),
|
||||
access_token TEXT,
|
||||
is_equipped BOOLEAN DEFAULT false,
|
||||
equipped_to VARCHAR(50)
|
||||
);
|
||||
```
|
||||
|
||||
#### 2. Gateway /api/stats JWT 검증 추가
|
||||
```python
|
||||
# Gateway main.py Line 283 수정
|
||||
@app.get("/api/stats/{robeing_id}")
|
||||
async def get_stats(
|
||||
robeing_id: str,
|
||||
x_user_id: str = Depends(get_verified_user) # JWT 검증 추가
|
||||
):
|
||||
# 현재는 x_user_id: Optional[str] = Header(None)로 취약
|
||||
```
|
||||
#### 2. Slack OAuth 플로우
|
||||
- 웹 로그인 → Slack 연결 버튼
|
||||
- Slack OAuth → 토큰 저장
|
||||
- 아이템 획듍 → 장착
|
||||
|
||||
### 5.2 중기 개선 (Phase 2)
|
||||
#### 3. Slack 이벤트 처리
|
||||
- slack_user_id로 slack_tokens 조회
|
||||
- user_id(UUID) 획듍
|
||||
- 모든 처리 UUID로 통일
|
||||
|
||||
1. **인증 체계 통합**
|
||||
- Slack과 웹 경로 통합 또는 명확한 분리
|
||||
- 모든 서비스에 일관된 인증 정책
|
||||
- X-User-Id 헤더 직접 신뢰 제거
|
||||
|
||||
2. **서비스 간 통신 보안**
|
||||
- 내부 API 키 또는 mTLS 적용
|
||||
- 서비스 메시 아키텍처 검토
|
||||
|
||||
3. **감사 로깅**
|
||||
- 모든 인증 시도 기록
|
||||
- 실패한 접근 모니터링
|
||||
#### 4. 기존 개선사항
|
||||
- Gateway /api/stats JWT 검증 추가
|
||||
- X-User-Id 직접 신뢰 제거
|
||||
|
||||
---
|
||||
|
||||
@ -213,15 +199,13 @@ curl -X GET http://gateway:8100/api/stats/rb8001 \
|
||||
|
||||
## 10. 결론
|
||||
|
||||
**🔴 이중 인증 체계 문제 - 통합 필요**
|
||||
**Slack 권한 아이템화로 통합 인증 체계 구축**
|
||||
|
||||
확인된 주요 문제:
|
||||
1. **웹 vs Slack**: JWT/UUID vs Slack ID 이중 체계
|
||||
2. **Gateway**: /api/stats 엔드포인트 JWT 검증 누락
|
||||
3. **서비스 간 통신**: 통일된 인증 없이 파라미터 신뢰
|
||||
4. **rb10508_micro**: X-User-Id 헤더만 신뢰
|
||||
|
||||
모든 경로에 일관된 인증 체계를 구축하거나, Slack과 웹을 명확히 분리해야 합니다.
|
||||
해결 방안:
|
||||
1. **Slack을 아이템으로**: Gmail과 동일한 UX
|
||||
2. **웹 UUID 중심**: 모든 채널 UUID로 통합
|
||||
3. **매핑 테이블**: slack_tokens로 관리
|
||||
4. **기억 통합**: 모든 대화 하나의 사용자로 관리
|
||||
|
||||
모든 서비스에 JWT 인증을 구현하고, Gateway에서 일관된 검증을 수행해야 합니다.
|
||||
|
||||
|
||||
@ -20,26 +20,45 @@
|
||||
- 채널 간 대화 기록 단절
|
||||
- 개인화 컨텍스트 손실
|
||||
|
||||
## 해결 방안: 분리 운영
|
||||
## 해결 방안: Slack 권한 아이템화
|
||||
|
||||
### 선택한 방안
|
||||
- **Slack과 웹을 별도 체계로 운영**
|
||||
- Slack: Slack ID + Slack 서명 검증
|
||||
- 웹: UUID + JWT 검증
|
||||
### 새로운 방안
|
||||
- **Slack을 아이템으로 관리**
|
||||
- 웹에서 Slack OAuth 인증 → slack_tokens 테이블 저장
|
||||
- Gmail 아이템과 동일한 방식으로 장착/해제
|
||||
|
||||
### 구현
|
||||
1. conversation_logs 테이블 현 구조 유지
|
||||
- slack_user_id: Slack 사용자만
|
||||
- user_id: 웹 사용자만
|
||||
1. **slack_tokens 테이블 생성**
|
||||
```sql
|
||||
CREATE TABLE slack_tokens (
|
||||
id SERIAL PRIMARY KEY,
|
||||
user_id UUID NOT NULL, -- 웹 사용자 UUID
|
||||
slack_user_id VARCHAR(100), -- Slack ID
|
||||
slack_team_id VARCHAR(100), -- Workspace ID
|
||||
access_token TEXT,
|
||||
is_equipped BOOLEAN DEFAULT false,
|
||||
equipped_to VARCHAR(50), -- 장착된 로빙
|
||||
created_at TIMESTAMP DEFAULT NOW()
|
||||
);
|
||||
```
|
||||
|
||||
2. 통계 조회 시 JOIN
|
||||
- slack_user_mapping 테이블 활용
|
||||
- WHERE user_id = ? OR slack_user_id IN (SELECT...)
|
||||
2. **인증 플로우**
|
||||
- 웹 로그인 (JWT) → Slack 연결 버튼
|
||||
- Slack OAuth → slack_tokens 저장
|
||||
- Slack 아이템 획득 → 장착 시 활성화
|
||||
|
||||
3. **Slack 이벤트 처리**
|
||||
- slack_user_id로 slack_tokens 조회
|
||||
- user_id(UUID) 획득 → 이후 UUID로 모든 처리
|
||||
|
||||
## 장점
|
||||
- **완벽한 ID 통합**: 웹 UUID가 primary identifier
|
||||
- **일관된 UX**: Gmail과 동일한 아이템 시스템
|
||||
- **권한 제어**: 장착/해제로 Slack 기능 활성화
|
||||
- **기억 통합**: 모든 채널의 대화가 하나의 UUID로 관리
|
||||
|
||||
## 결론
|
||||
- 분리 운영이 가장 현실적
|
||||
- 각 채널 특성에 맞는 인증 체계 유지
|
||||
- 필요 시 slack_user_mapping 테이블로 통합 조회
|
||||
Slack을 아이템으로 관리하면 분리 운영 문제 완전 해결. 웹에서 시작하여 Slack을 연결하는 방식으로 통합 인증 체계 구축.
|
||||
|
||||
---
|
||||
*작성: Claude*
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user