대상 OS: Rocky Linux 9
보안 감사를 받거나 규제 환경에 들어가면, 결국 ‘암호화가 표준을 만족하느냐’가 질문으로 돌아옵니다.
그때 문제가 되는 건 보통 기술 자체가 아니라 “서버마다 암호 설정이 제각각”이라는 운영 현실입니다.
어떤 서버는 오래된 TLS 옵션이 남아 있고, 어떤 서버는 SSH 알고리즘이 느슨하고, 어떤 서버는 라이브러리 정책이 다릅니다.
Rocky Linux 9에서는 FIPS 모드와 crypto-policies를 이용해 암호 정책을 운영 표준으로 맞추는 선택지가 있습니다.
이 글은 Rocky Linux 9에서 FIPS 모드를 활성화하는 절차와, 활성화 후 OpenSSH/TLS(웹 서버/클라이언트)에 생기는 영향, 그리고 운영에서 자주 터지는 호환성 문제를 어떻게 진단/대응할지 정리합니다.
---
1) FIPS 모드가 ‘무엇을’ 바꾸는가
1)
커널/암호 라이브러리(OpenSSL 등)의 허용 알고리즘이 더 보수적으로 제한된다
2)
시스템 전반의 암호 정책이 표준화되면서, “서버별 편차”가 줄어든다
3)
구형/비표준 암호군을 쓰던 레거시 클라이언트가 접속 실패할 수 있다
4)
운영 변경 비용(테스트/검증/롤백)이 생기므로, 점진 롤아웃이 필요하다
주의
- FIPS 모드는 단순 토글이 아니라, 시스템 전체의 암호 동작을 바꾸는 큰 변경입니다.
- 특히 오래된 에이전트/레거시 장비와의 호환성 이슈가 ‘실제 장애’로 이어질 수 있습니다.
---
2) 적용 전 점검: 지금 서버의 암호 정책/서비스 상태
1)
현재 crypto-policies 상태 확인
update-crypto-policies --show2)
OpenSSL/SSH 버전 확인(환경 스냅샷)
openssl version -a
ssh -V3)
외부 노출 서비스 확인(호환성 영향 우선순위)
sudo ss -ltnp | head -n 80
sudo ss -lunp | head -n 804)
중요: 콘솔 접근 가능 여부 확인
FIPS 전환은 재부팅을 동반하는 경우가 많습니다. 원격만으로 진행하면 리스크가 큽니다.
---
3) FIPS 모드 활성화(핵심 절차)
Rocky/RHEL 계열에서는 fips-mode-setup을 사용합니다.
1)
도구 설치(없다면)
sudo dnf -y install fips-mode-setup2)
현재 상태 확인
sudo fips-mode-setup --check3)
FIPS 모드 활성화
sudo fips-mode-setup --enable이 단계에서 initramfs 재생성/부트 파라미터 변경 등이 안내될 수 있습니다.
4)
재부팅
sudo systemctl reboot---
4) 부팅 후 검증: “진짜 FIPS로 올라왔는지” 확인
1)
커널 FIPS 플래그 확인
cat /proc/sys/crypto/fips_enabled`1`이면 FIPS가 활성화된 상태입니다.
2)
fips-mode-setup 체크
sudo fips-mode-setup --check3)
crypto-policies 상태 재확인
update-crypto-policies --show---
5) crypto-policies와의 관계: 운영 표준 만들기
FIPS 모드를 켰다고 해서 모든 서비스 설정이 자동으로 ‘이상적인’ 상태가 되는 건 아닙니다.
하지만 crypto-policies는 여러 구성요소가 공통으로 참고하는 정책이기 때문에, 표준화의 효과가 큽니다.
1)
정책을 무리하게 커스텀하기 전에 “기본 정책”을 먼저 이해
update-crypto-policies --show2)
정책 변경은 반드시 테스트 환경에서
sudo update-crypto-policies --set DEFAULT
update-crypto-policies --show(이 명령은 예시이며, 실제로는 조직 표준 정책과 FIPS 요구를 함께 고려해야 합니다.)
주의
- 운영 서버에서 임의로 crypto-policies를 바꾸면 TLS/SSH 호환성이 한 번에 깨질 수 있습니다.
---
6) 영향 범위 점검: OpenSSH에서 가장 먼저 확인할 것
FIPS 전환 후 SSH 접속이 안 되면 운영이 멈춥니다.
따라서 SSH는 가장 먼저 점검합니다.
1)
sshd 유효 설정 확인(암호/키 교환 관련)
sudo sshd -T | grep -E 'kexalgorithms|ciphers|macs|hostkeyalgorithms|pubkeyacceptedalgorithms' | head -n 802)
클라이언트에서 실제 협상 확인
ssh -vvv [email protected] 2>&1 | grep -E 'kex: algorithm|kex: host key algorithm|kex: cipher|kex: mac' | head -n 60운영 팁
- 레거시 장비가 RSA/SHA1, 구형 KEX에 의존하면 접속이 끊길 수 있습니다.
- 이 경우 “레거시를 점프서버로 격리”하는 방식이 가장 안전합니다.
---
7) 영향 범위 점검: TLS(웹/프록시) 검증 방법
FIPS는 TLS에서도 구형 알고리즘/암호군이 차단될 수 있습니다.
실제 핸드셰이크로 확인하는 것이 가장 확실합니다.
1)
TLS 접속 테스트(프로토콜/암호 확인)
openssl s_client -connect your.domain:443 -tls1_2 2>/dev/null | grep -E 'Protocol|Cipher' | head -n 202)
TLS 1.3 테스트(서비스가 지원한다면)
openssl s_client -connect your.domain:443 -tls1_3 2>/dev/null | grep -E 'Protocol|Cipher' | head -n 20---
8) 운영 트러블슈팅 TOP 6
1)
재부팅 후에도 fips_enabled가 0
cat /proc/sys/crypto/fips_enabled
sudo fips-mode-setup --check2)
SSH 접속이 갑자기 안 됨
- 클라이언트가 구형 알고리즘만 지원하는 경우가 많음
- 다른 최신 클라이언트로 접속 시도해 원인 분리
ssh -Q kex | head -n 40
ssh -Q cipher | head -n 40
ssh -Q mac | head -n 403)
TLS 클라이언트(레거시 Java/임베디드)가 접속 실패
- 예외를 전체 서버에 풀지 말고, 별도 엔드포인트/별도 레거시 존으로 분리
4)
특정 에이전트/패키지가 암호 라이브러리 정책 때문에 기동 실패
sudo journalctl -n 200 --no-pager | tail -n 1205)
성능/지연이 민감한 환경
- 암호 정책 변경은 CPU 사용 패턴을 바꿀 수 있음
- 롤아웃 전후로 지표(응답시간/CPU)를 비교
uptime
vmstat 1 56)
“한 대만” 문제가 생김
- 서버별 crypto-policies/패키지 버전 편차가 원인일 수 있음
update-crypto-policies --show
rpm -q openssl openssh-server 2>/dev/null || true---
9) 롤백(비활성화) 계획도 같이 가져가기
규제/정책이 허용한다면, 실패 시 빠른 롤백 경로를 알아두는 것이 운영 안전장치입니다.
1)
FIPS 모드 비활성화
sudo fips-mode-setup --disable2)
재부팅
sudo systemctl reboot3)
비활성화 확인
cat /proc/sys/crypto/fips_enabled
sudo fips-mode-setup --check주의
- 롤백도 시스템 전체 암호 정책이 바뀌는 작업이라, 동일하게 검증이 필요합니다.
---
마무리
Rocky Linux 9의 FIPS 모드는 “암호 정책을 통제 가능한 표준”으로 만드는 강한 선택지입니다.
다만 강한 만큼 호환성/운영 비용이 뒤따르므로, 반드시
- 적용 전 서비스/클라이언트 호환성 파악
- 콘솔 접근/재부팅 창구 확보
- SSH/TLS 우선 검증
- 점진 롤아웃 + 롤백 플랜
을 함께 가져가야 합니다.
암호 표준화는 보안팀의 요구만이 아니라, 운영팀이 사고 대응 타임라인을 지키는 기반이기도 합니다.