SSH에서 마이그레이션

기존 SSH 키 관리에서 Alpacon의 제로 트러스트 아키텍처로 전환하면 보안 강화, 감사 추적 개선, 액세스 관리 간소화를 실현할 수 있습니다. 이 가이드는 단계별 마이그레이션 프로세스를 안내합니다.

왜 SSH에서 마이그레이션해야 할까요?

SSH 키 관리의 문제점

기존 SSH는 여러 운영상 문제를 야기합니다:

• 키 확산: SSH 키가 중앙 추적 없이 서버 전체에 확산됨
• 만료 없음: 수동으로 교체하지 않는 한 키가 무기한 유효함
• 제한된 감사 추적: 누가 언제 무엇에 액세스했는지 추적하기 어려움
• 복잡한 키 교체: 수동 프로세스로 인해 오류와 서비스 중단 발생
• 공유 계정: 여러 사용자가 동일한 SSH 사용자 계정을 공유
• 키 분실: 장치가 손상된 경우 원격으로 액세스를 취소할 방법이 없음

Alpacon의 장점

Alpacon은 다음과 같은 방식으로 이러한 문제를 해결합니다:

• 중앙 집중식 액세스 제어: 단일 대시보드에서 모든 액세스 관리
• 시간 제한 토큰: 액세스가 자동으로 만료됨
• 완전한 감사 로그: 모든 명령과 작업이 기록됨
• 즉시 취소: 웹 콘솔에서 즉시 액세스 제거
• 개별 책임성: 각 사용자가 자신의 고유 ID를 가짐
• 노출된 포트 없음: 서버가 인터넷에 SSH 포트를 열 필요 없음

마이그레이션 전략

1단계: 병렬 운영 (권장)

처음에는 Alpacon을 SSH와 함께 실행하면 원활하고 위험 없는 전환이 가능합니다.

1. Alpacon 에이전트 설치 - SSH를 활성화한 상태에서 서버에 설치
2. 연결 테스트 - Alpacon 웹 콘솔을 통해 테스트
3. 액세스 권한 부여 - Alpacon을 통해 팀원에게 액세스 권한 부여
4. 사용량 모니터링 - 모든 워크플로가 지원되는지 확인
5. SSH 키 사용 점진적 감소
6. SSH 비활성화 - Alpacon에 대한 확신이 생기면 비활성화

2단계: 사용자 마이그레이션

기존 액세스 인벤토리

먼저 현재 SSH 액세스를 감사합니다:

# 서버의 모든 authorized keys 나열
find /home -name "authorized_keys" -exec ls -la {} \;
 
# SSH 구성 확인
cat /etc/ssh/sshd_config | grep -E "^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)"
 
# sudo 권한 검토
cat /etc/sudoers
getent group sudo

Alpacon 역할에 사용자 매핑

3단계: 워크플로 마이그레이션

대화형 세션

이전 (SSH):

ssh user@server.example.com

이후 (Alpacon):

alpacon websh connect production-server
# 또는 웹 콘솔 사용: https://alpacon.io/workspace

파일 전송

이전 (SCP/SFTP):

scp file.txt user@server:/path/to/destination

이후 (Alpacon WebFTP):

• Alpacon 콘솔에서 WebFTP 인터페이스 사용
• 브라우저에서 직접 파일을 드래그 앤 드롭
• 또는 CLI 사용: alpacon ftp upload file.txt /path/to/destination

자동화 및 CI/CD

이전 (GitHub Actions에서 SSH):

- name: Deploy via SSH
  uses: appleboy/ssh-action@v0.1.5
  with:
    host: ${{ secrets.HOST }}
    username: ${{ secrets.USERNAME }}
    key: ${{ secrets.SSH_KEY }}
    script: |
      cd /app
      git pull
      npm install
      pm2 restart app

이후 (GitHub Actions에서 Alpacon):

- name: Deploy via Alpacon
  uses: alpacax/alpacon-websh-action@v1.0.0
  with:
    workspace-url: ${{ secrets.ALPACON_WORKSPACE_URL }}
    api-token: ${{ secrets.ALPACON_API_TOKEN }}
    target: 'production-server'
    script: |
      cd /app
      git pull
      npm install
      pm2 restart app

서드파티 도구 API 통합

네이티브 Alpacon 지원이 없는 도구의 경우 REST API를 사용하세요:

# REST API를 통해 명령 실행
curl -X POST https://your-workspace.us1.alpacon.io/api/events/commands/ \
  -H "Authorization: Bearer $ALPACON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "server": "production-server",
    "command": "systemctl restart nginx",
    "timeout": 300
  }'

전체 문서는 API 레퍼런스를 참조하세요.

마이그레이션 체크리스트

마이그레이션 진행 상황을 추적하려면 이 체크리스트를 사용하세요:

준비 단계

• 모든 SSH 키와 구성 백업
• 현재 사용자와 권한 문서화
• Alpacon 워크스페이스 생성
• 마이그레이션 일정 계획
• 중요한 워크플로 식별

구현 단계

• 모든 대상 서버에 Alpamon 설치
• 워크스페이스에 서버 등록
• 사용자 그룹 및 역할 구성
• CI/CD 파이프라인 업데이트
• 모니터링 및 알림 설정
• 모든 팀원의 액세스 테스트

검증 단계

• 모든 사용자가 서버에 액세스할 수 있는지 확인
• 모든 CI/CD 파이프라인 테스트
• 감사 로그 검토
• 성능 메트릭 검증
• 문제 또는 해결 방법 문서화

완료 단계

• SSH 포트 비활성화
• SSH 키 제거
• 문서 업데이트
• 팀 교육 완료
• 마이그레이션 후 검토 일정 잡기

보안 고려사항

SSH 비활성화 전

SSH 액세스를 비활성화하기 전에 다음 항목이 완료되었는지 확인하세요:

• 모든 팀원이 Alpacon 액세스를 구성함
• 긴급 액세스 절차가 문서화됨
• 백업 액세스 방법을 사용할 수 있음 (콘솔/IPMI)
• 모니터링 알림이 Alpacon을 사용하도록 업데이트됨
• 자동화 스크립트가 API 토큰을 사용하도록 마이그레이션됨
• 제한된 사용자에 대해 명령 ACL이 구성됨

마이그레이션 후 강화

Alpacon으로 마이그레이션한 후:

1. SSH 서비스 비활성화:

# SSH 데몬 비활성화
sudo systemctl disable sshd
sudo systemctl stop sshd

2. 방화벽 포트 닫기:

# 방화벽에서 SSH 포트 제거
sudo ufw delete allow 22/tcp

3. authorized keys 제거:

# 오래된 SSH 키 정리
find /home -name "authorized_keys" -exec rm {} \;
find /root -name "authorized_keys" -exec rm {} \;

롤백 계획

SSH 액세스를 다시 활성화해야 하는 경우:

1. Alpacon 콘솔을 통해:

# SSH 서비스 재활성화
sudo systemctl enable sshd
sudo systemctl start sshd
 
# 방화벽 포트 열기
sudo ufw allow 22/tcp
 
# 긴급 SSH 키 추가
echo "ssh-rsa YOUR_EMERGENCY_KEY" >> ~/.ssh/authorized_keys

2. 물리적/콘솔 액세스를 통해:

• 클라우드 제공업체의 콘솔 액세스 사용 (AWS Systems Manager, GCP Serial Console)
• 사용 가능한 경우 IPMI/iDRAC를 통해 서버에 액세스
• 온프레미스 서버에 대한 물리적 액세스

일반적인 마이그레이션 시나리오

개발 서버

초기 마이그레이션에 이상적인 저위험 서버:

1. Alpacon 에이전트 설치
2. 모든 개발 워크플로 테스트
3. 팀 피드백 수집
4. 학습한 내용을 프로덕션 마이그레이션에 적용

프로덕션 서버

신중한 계획이 필요함:

1. 유지보수 기간 예약
2. 모든 이해 관계자에게 알림
3. 먼저 스테이징 환경에서 테스트
4. 롤백 계획 준비
5. 마이그레이션 후 면밀히 모니터링

레거시 시스템

즉시 마이그레이션할 수 없는 시스템:

1. 별도의 네트워크 세그먼트에서 레거시 서버 격리
2. 단일 진입점으로 Alpacon 점프 서버 사용
3. 점진적으로 현대화 및 마이그레이션
4. 규정 준수를 위한 엄격한 감사 로그 유지

마이그레이션 문제 해결

”마이그레이션 후 연결할 수 없음”

확인 사항:

• Alpacon 에이전트가 실행 중인지: systemctl status alpamon
• 서버가 워크스페이스에 등록되었는지
• 사용자에게 적절한 권한이 있는지
• 방화벽이 아웃바운드 HTTPS(포트 443)를 허용하는지

”자동화 스크립트 실패”

확인 사항:

• API 토큰에 필요한 권한이 있는지
• 명령 ACL이 필요한 명령을 허용하는지
• 환경 변수가 올바르게 설정되었는지
• 스크립트 경로가 상대 경로가 아닌 절대 경로인지

”파일 전송이 작동하지 않음”

확인 사항:

• 워크스페이스에 WebFTP가 활성화되어 있는지
• 사용자에게 파일 전송 권한이 있는지
• 대상 디렉터리에 적절한 권한이 있는지
• 사용 가능한 디스크 공간이 충분한지

다음 단계

• 보안 모범 사례 검토
• 모니터링 및 알림 설정
• 명령 ACL 구성
• 감사 로그 보관 구현

도움이 필요하신가요?

• 마이그레이션 지원을 위해 Discord 커뮤니티에 가입하세요
• 이메일: support@alpacax.com
• 문서: 문제 해결 가이드