pam

RDS CA 인증서 2015 -> 2019 변경

메일을 받았다.

Hello,

Please act before October 31, 2019 to address an upcoming interruption of your applications using RDS and Aurora database instances.

To protect your communications with RDS database instances, a Certificate Authority (CA) generates time-bound certificates that are checked by your database client software to authenticate any RDS database instance(s) before exchanging information. Following industry best practices, AWS renews the CA and creates new certificates on a routine basis to ensure RDS customer connections are properly protected for years to come. The current CA expires on March 5, 2020, requiring updates to existing RDS database instances with certificates referencing the current CA.

You are receiving this message because you have an Amazon RDS database instance(s) in the AP-NORTHEAST-1, AP-NORTHEAST-2, AP-SOUTHEAST-1, AP-SOUTHEAST-2 Region(s). If your applications connect to those instances using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol please follow the detailed instructions in the link below to complete your update(s). If not completed, your applications will fail to connect to your DB instances using SSL/TLS after March 5, 2020.

We encourage you to test these steps within a development or staging environment before implementing them in your production environments. Beginning today, you can start testing and updating your existing RDS database instances. For detailed instructions, please visit: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html

Any new RDS instances created after November 1, 2019 will default to using the new certificates. If you wish to temporarily modify new instances manually to use the old (rds-ca-2015) certificates, you can do so using the AWS console or the AWS CLI. Any instances created prior to November 1, 2019 will have the rds-ca-2015 certificates until you update them to the rds-ca-2019 version.

If you have questions or issues, please contact AWS Support at: https://aws.amazon.com/support

Sincerely,
Amazon Web Services

rds의 ca 인증서가 2015에서 2019로 변경되었다. 간단한 테스트를 진행할거고 변경을 진행할것이다.

먼저 진행할 테스트는 ca-2015 인증기관과 중간 인증서로 접속하기다. 처음엔 글로벌 CA를 이용할거라 생각했는데 아니었다. 리전마다 중간인증서로 명명된 CA인증서를 사용해야 한다.

접속 정보는 이미 모두 적용된 세션에 SSL CA 만 추가해서 접속한다

사용한 인증서는 RDS 에선 CA-2015 그리고 SSL CA인증서는 아마존에서 제공하는 중간인증서를 사용하였다.

https://s3.amazonaws.com/rds-downloads/rds-ca-2015-ap-northeast-2.pem

위 인증서를 받아서 접속을 하였다.

/* 구분자를 ";" 으(로) 변경 / / linuxer-blog-rds.ctekipxl.ap-northeast-2.rds.amazonaws.com 에 MariaDB (SSH tunnel) 을(를) 통해 연결 중, 사용자 이름 "admin", 암호 사용: Yes… / / SSL 매개 변수를 성공적으로 설정하였습니다. / / Attempt to create plink.exe process, waiting 4s for response … / /
/ SELECT CONNECTION_ID(); / 연결됨. 스레드-ID: 579 / / 문자 집합: utf8mb4 */

정상적으로 접근이 가능한것을 확인하였다.

인증서 다운로드 리스트는 아래의 링크이다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html

그럼 이제 테스트할것은 RDS CA-2015 을 CA-2019 로변경하고 rds-ca-2015-ap-northeast-2.pem 인증서로 접근해 볼것이다. 인증기관을 변경하는 방법은 다음과 같다.

수정을 누르고~ 스크롤을 내린다.

인증기관 부분을 2015 -> 2019로 변경한다.

변경하면 위와같은 노티가 발생한다. 새인증서를 받아서 사용하라는 메시지 이다.

2분가량의 다운 타임이 발생하고 이테스트를 진행하는 이유는 다음 글귀 때문이다.

aws docs 에서 본 글귀인데

이 루트 인증서는 신뢰할 수 있는 루트 개체이므로 대부분의 경우에 작동하지만 애플리케이션에서 인증서 체인을 수락하지 않는 경우 실패할 수 있습니다.

대부분의 경우에 작동한다. 물론 2015-2019 인증서가 교차로 작동할거라 생각하진 않으나 혹시나 하는 생각에 진행해 본다.

tmi로

유지관리 기간 설정은 같은 페이지에서 할 수 있다. 즉시 적용을 하지 않을 계획이라면 알아두자. 필자는 즉시적용을 했다.

재부팅이 이어지고 완료가 되면 접속테스트를 진행한다.

CA-2019 인지라 rds-ca-2015-ap-northeast-2.pem 인증서론 접근이 안된다.

이후 사용한 인증서는 아래의 링크이다. 접속이 잘된다.

https://s3.amazonaws.com/rds-downloads/rds-ca-2019-ap-northeast-2.pem

HeidiSQL 프로그램으로 SSL을 사용한 접근을 하는 테스트를 진행해 보았다.

이테스트를 진행한 이유는 사실 목적은 읽기전용복제본에 있었다.

CA인증서가 변경되면서 master - slave 사이의 통신채널에도 문제가 있을까? 하는 질문을 받았기 떄문이다.

https://aws.amazon.com/ko/rds/details/read-replicas/

보안을 고려한 설계
Amazon RDS for MySQL, Amazon RDS for MariaDB 및 Amazon RDS for PostgreSQL의 읽기 전용 복제본을 생성할 때, Amazon RDS는 리전 간에 복제하더라도 원본 DB 인스턴스와 읽기 전용 복제본 간에 퍼블릭 키 암호화를 사용하여 안전한 통신 채널을 설정합니다. Amazon RDS는 안전한 채널을 제공하는 데 필요한 모든 AWS 보안 구성(예: 보안 그룹 항목을 추가)을 설정합니다.

퍼블릭키 암호화 부분이 CA를 사용하는건 아닐까하는 궁금증이었는데,

스크린샷을 찍어가며 작업한것은 아니나, CA-2015 에서 생성한 읽기전용복제본의 인증기관을 2015 로 설정하고 마스터는 CA-2019 로 변경시에 퍼블릭키를 이용한 암호화 채널에는 아무 문제가 없었다.

고로 퍼블릭 키는 별도의 퍼블릭키라 결론을 내렸다.

현재 CA-2015 에서 CA-2019로 교체이슈가 뜨겁다.

즉시적용이던 유지관리에 적용이던 얼른적용하자.
사실 RDS에서 SSL 인증을 사용하는것이 아니면 기능상의 문제는 없으나....

이벤트에 의해 강제로 리부팅되고 단절에의해 서비스에 장애가 생기는거 보단 미리하는것이 나을것이라 생각한다.

한섭님의 좋은 궁금증이었다.

한섭님께 감사를 드린다!

ubuntu 16.04 pam 패스워드 유효성 제한 libpam-pwquality 설정 포함

패스워드 유효성 검증

로그인 실패 5 계정 잠금 5분
#vi /etc/pam.d/common-auth
16번째줄 삽입
auth required pam_tally2.so file=/var/log/tallylog deny=5 even_deny_root unlock_time=300

#vi /etc/pam.d/common-account
16 줄에 삽입
account required pam_tally2.so

패스워드 만료 모듈 설치
#apt-get -y install libpam-pwquality

패스워드 만료 모듈의 경우에는 사용자를 새로 만들때만 영향을 줍니다.
따라서 기존유저에 적용시에는 명령어로 지정해주어야 합니다.

패스워드 사용가능 최대 기간
#chage -m (days) (user)

PASS_MAX_DAYS 180

패스워드 사용가능 최소 기간
#chage -m (days) (user)

PASS_MIN_DAYS 2

패스워드 만료전 경고 일수
#chage -W (days) (user)

PASS_WARN_AGE 7

패스워드 사용시간 제한

#vi /etc/login.defs
PASS_MAX_DAYS 180

#vi /etc/pam.d/common-password
password requisite pam_pwquality.so retry=3 minlen=10 minclass=3
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 remember=2

remember=2 2회 동안 동일한 비밀번호 생성 금지
minlen=10 비밀번호 길이 생성 제한 10자 이상으로
minclass=3 새비밀번호에 필요한 문자 클래스 수 제한 (종류 ⇒ 대문자 / 소문자 / 숫자 / 기타)

참조 URL
https://www.server-world.info/en/note?os=Ubuntu_16.04&p=password

isms 기준에 맞춘 ubuntu 16.04 ssh 패스워드 유효성 설정입니다.