드디어!!드디어!!드디어!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! AWS에도 웹모니터링 기능이 생겼다. 진짜 너무 기다려왔던 기능이다. 사용법도 간단하고 지표도 바로나오고..이거 완전 물건이다. 바로 셋팅해봤다. 블루 프린트를 사용해서 테스트를 했다. 4가지의 블루프린트를 제공하고 스크립트를 수정할수도 있으나 귀찮다. 일정은 뭐....알아서 나는 5분으로 만들고 나중에 1분으로 수정했다. 일단 나머지 파라메터를 다 기본으로 설정하고 진행했다. 생성하면 진짜 간단하게 보여준다. 핵심은 이거다. 그냥 사이트 모니터링을 해주고 지연된 URL을 체크해준다. 나같은경우엔 사이트 모니터링을 1분마다 하고 5분 평균 임계값을 1로 설정하여 상당히 예민한 모니터링 설정을 하였다. 사이트 URL 체크가 1번만 실패해도 SNS로 경보가 동작한다. ...
https://www.facebook.com/groups/awskrug/permalink/2404835746285102/ 다음과 같은 질문이 올라왔다. 바로 생각난건 general_log.. 그래서 Master와 Readreplica 가 각각 다른 Parameter Group(이하 PG)를 가질수 있는지 확인해보기로 했다. 먼저 Readreplica 생성했다. 실제로 읽기복제본을 만들때는 파라메터 그룹을 수정할수 없다. Master 의 PG를 그대로 사용한다. 이렇게 모두 생성된 Readreplica 를 수정을 눌러보면 데이터베이스 옵션에서 파라메터 그룹을 볼수있다. 그래서 나는 따로 PG를 만들어주고..general_log 도 켜줬다. dynamic / static 으로 나뉘는데 적용유형이 dynamic이면 PG가 적용된상태에서 라이브로 적용된다. 디비의 재시작이 필요없다. ...
aws 관리형키를 사용할 경우 sns 암호화를 하면 cloudwatch 에서 호출이 안된다.... 작업 arn:aws:sns:ap-northeast-2:userid:sns_topic을(를) 실행하지 못했습니다. 수신 오류: 'null (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: 60c4ef-f3bb-4c89-98c8-67317fc18a)' 이런 에러가 발생한다. 이경우 CMK 를 이용해서 SNS 암호화를 해야한다. https://aws.amazon.com/ko/premiumsupport/knowledge-center/cloudwatch-receive-sns-for-alarm-trigger/ 다음 링크를 참조했다. 위와 같은 구성으로 생성하고 정책을 적용한다. { "Version": "2012-10-17", "Id": "EMR-System-KeyPolicy", "Statement": [ { "Sid": "Allow access for Root User", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::userid:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrator", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::userid:root" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access for Key User (SNS IAM User)", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::userid:root" }, "Action": [ "kms:GenerateDataKey*", "kms:Decrypt" ], "Resource": "*" }, { "Sid": "Allow access for Key User (SNS Service Principal)", "Effect": "Allow", "Principal": { "Service": [ "sns.amazonaws.com", "cloudwatch.amazonaws.com" ] }, "Action": [ "kms:GenerateDataKey*", "kms:Decrypt" ], "Resource": "*" } ] } ...
오늘은 s3 delete 를 mfa 로 제한하는 방법에 대해서 포스팅 해보겠다. aws 에서 s3 버킷에 대한 삭제 제한을 해야 할때가 있다. 이경우에 root access key를 생성하여야 한다. iam 대시보드에서 mfa 와 루트 엑세스키를 생성할수 있다. 보안자격증명 관리로 이동해서 진행한다. 과정은 간단하고 쉬우니 URL을 참고하자. https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_mfa.html - MFA 활성화 https://docs.aws.amazon.com/ko_kr/general/latest/gr/managing-aws-access-keys.html -access key 생성 생성한 키로 aws cli 를 사용가능하도록 설정한다 /root/.aws/credentials 다음 위치다. access key를 넣고 mfa 를 확인해보자 ...
EBS 암호화 과정을 포스팅 하겠다. 일반적으로 EBS는 기본이 암호화를 하지 않도록 설정되어있다. 이미 생성된 볼륨을 암호화 할 순 없다. 따라서 이미 생성된 인스턴스에 연결된 EBS를 암호화 하기위해선 다음과 같은 과정을 거쳐야 한다. 인스턴스종료-스냅샷-EBS 암호화로 볼륨 생성-인스턴스에서 볼륨분리-암호화된 볼륨 연결-인스턴스시작. 암호화 되지 않은 볼륨이 있다. 이볼륨을 암호화 할거다. 인스턴스를 중지한다. 임시스토리지 유실 안내가 나온다. 인스턴스가 중지되면 연결된 EBS를 찾아서 스냅샷을 진행한다. tag 를 Name 로 설정하여 잘적자. 생성된 스냅샷으로 볼륨을 생성한다. ...
그 동안 블로그를 운영하면서 블로그에 이것저것 적용해 보느라 시간 가는줄 몰랐다. 대략적인 블로그의 구성도를 그려보았고 구성도를 하나하나 풀어보는 시간을 가져보려한다. 먼저 내블로그는 apm 으로 이루어진 상태였다. 프리티어로 도메인도 없는 상태였고 그냥 테스트 용도 였다. 그 블로그를 먼저 rds 로 분리를 진행 했다. 인스턴스한대에 apache + php + mariadb 였던 구성에서 mariadb 를 rds 로 옮겼다. 그리고 php를 php-fpm 으로 교체 했다. 이시기엔 그냥 구성만 진행하려던 시기라 뭔가 많이 붙이지 않았다. 이 다음 과정에서 로드벨런서를 붙였다. ...
Hostcenter 의 Acunetix 취약점 점검툴을 사용하였습니다. https://www.hostcenter.co.kr/Security/security01.aspx aws waf.ver2 관리형룰의 성능을 테스트 하고 싶었다. 마침 회사에 web 취약점 점검툴이 있었다. 그래서 테스트를 진행했다. 먼저 COUNT 모드로 점검을 진행했다. 총 점검시간 4시간 15000번의 리퀘스트가 있었다. 첫번째 테스트는 1월10일 두번째 테스트는 1월 30일 이었다. 빨리 진행하고 싶었는데 좀 바빳다. 1월10일 모니터링 모드 스캔 결과 1월 30일 차단모드 스캔결과 간략한 결과로만 봐도 high단계의 취약점이 사라리고 medium 단계의 취약점이 하나 사라졌다. 그럼 어떻게 막혔는지 리뷰를 해야하는데... ...
waf 가 리뉴얼 되어 ver2로 돌아왔다. 그동안엔 cloudformation을 이용하여 waf 사용했는데 이젠 그럴필요가 없어졌다. https://github.com/aws-samples/aws-waf-sample 이전에 사용하던 방법 또한 매니지드 룰을 제공하여 어느정도 패턴까지 지원해서 아주 긍정적이고 사용이 간단하며, 비용 또한 여타 웹 방화벽들보다 굉장히 싼편이라 적극 추천을 한다. 미사여구는 여기까지. 먼저 설정하는 방법을 설명하겠다. 불편한 점은.. ACL 확인시에 페이지르 변경하게 되면 리전설정을 매번 다시해줘야한다는거.. overview 가 갱신이 느리다는거...완전 답답..그래도 거의 실시간으로 차단된부분을 보여주는거나 이렇게 그래프에서 드래그를 하면 그시간대에 발생한 로그만 따로 보여주는점 등은 매우 사용자 친화적이라 할수있다. 그리고. ...
rds ha 를 테스트 해보았다. HA enable 활성화시에 다운타임은 없다. HA enble -> instance type 변경 t2.micro -> t2.small HA 동작 10.0.1.12->10.0.1.30 다운타임 3초내외 HA disable instance type 변경 t2.micro -> t2.small 동시설정 HA 동작 10.0.1.30 -> 10.0.1.13 다운타임 3초내외 나름 생각보다 빠른 fail over 였다.
요 며칠간 CF관련 이슈로 고민이 많았다. ipv6 부터 SK LTE까지... 이문제가 발생한 원인은 먼저 SK LTE DNS 에서의 ipv6라우팅이 가장 큰 원인일테고.. 같은 cloudfront에서도 발생하는 빈도차가 있었으므로 그 원인을 파악하고 해결하는 법을 서술하려고한다. 먼저 A alias는 ipv4로 라우팅한다. - A record 는 ipv4를 라우팅 하므로.. linuxer.name 이름: linuxer.name Addresses: 52.85.231.10 52.85.231.111 52.85.231.68 52.85.231.42 그렇다면 alias 를쓰는 사용자는 cf관련 문제를 겪지 않았을 것이다. Route 53 별칭 레코드는 AWS 리소스와 같은 별칭 대상의 DNS 이름에 내부적으로 매핑됩니다. Route 53은 조정 작업과 소프트웨어 업데이트를 위해 별칭 대상의 DNS 이름과 연결된 IP 주소를 모니터링합니다. Route 53 이름 서버의 신뢰할 수 있는 응답에는 A 레코드(IPv4 주소에 대한 레코드) 또는 AAAA 레코드(IPv6 주소에 대한 레코드)와 별칭 대상의 IP 주소가 포함되어 있습니다. https://aws.amazon.com/ko/premiumsupport/knowledge-center/route-53-create-alias-records/ ...