AWS-SCS-note

이아래로는 공부하면서 정리하고 AWS DOCS 에서 발췌한 내용이다.

https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/rotate-keys.html

이미지에 대체텍스트 속성이 없습니다; 파일명은 image.png 입니다.

AWS Secrets Manager

https://docs.aws.amazon.com/ko_kr/secretsmanager/latest/userguide/intro.html

Secrets Manager는 코드의 암호를 포함해 하드 코딩된 자격 증명을 Secrets Manager에서 프로그래밍 방식으로 보안 암호를 검색하도록 하는 API 호출로 바꿀 수 있습니다. 이렇게 하면 보안 암호가 코드에 더 이상 존재하지 않기 때문에 코드를 검사하는 누군가에 의해 보안 암호가 손상되지 않도록 방지할 수 있습니다. 또한 사용자가 지정된 일정에 따라 Secrets Manager가 자동으로 보안 암호를 교체하도록 구성할 수 있습니다. 따라서 단기 보안 암호로 장기 보안 암호를 교체할 수 있어 손상 위험이 크게 줄어듭니다.

AWS Systems Manager Parameter Store

파라미터 스토어는 애플리케이션 구성 및 보안 데이터를 위한 안전한 중앙 집중식 스토리지를 제공합니다. 파라미터 스토어를 사용하여 구성 데이터를 애플리케이션 코드와 분리할 수 있습니다. 파라미터 스토어는 표준 및 고급의 두 가지 파라미터 계층을 제공합니다. 표준 계층에서는 최대 10,000개의 파라미터와 값 크기로 파라미터당 4KB를 저장할 수 있으며, 고급 계층에서는 최대 100,000개의 파라미터와, 값 크기로 파라미터당 8KB를 저장하고 정책을 파라미터에 추가할 수 있습니다. 지능형 계층화를 통해 파라미터 스토어는 생성 요청 또는 업데이트 요청에서 요청된 기능을 기반으로 계층 선택을 자동화하여 중단 없는 방법으로 고급 계층 기능을 사용할 수 있도록 합니다. 예를 들어 지능형 계층화 설정을 사용하면 계정에 10,000개의 표준 파라미터가 초과되는 경우 후속 파라미터가 고급 파라미터로 만들어져 애플리케이션 코드를 변경할 필요가 없게 됩니다. 지능형 계층화는 기본 계층이라는 새로운 서비스 수준 설정에서 옵션으로 사용할 수 있습니다.

aws config

https://docs.aws.amazon.com/ko_kr/config/latest/developerguide/config-concepts.html

aws cloudtrail

https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf

vpc 침투테스트시 허가가 필요없는 서비스가 있음

. https://aws.amazon.com/security/penetration-testing/

허용

  • Amazon EC2 인스턴스, NAT 게이트웨이 및 Elastic Load Balancer
  • Amazon RDS
  • Amazon CloudFront
  • Amazon Aurora
  • Amazon API Gateway
  • AWS Lambda 및 Lambda Edge 기능
  • Amazon Lightsail 리소스
  • Amazon Elastic Beanstalk 환경

금지

Amazon Route 53 Hosted Zones를 통한 DNS zone walking

  • 서비스 거부 (DoS), 분산 서비스 거부 (DDoS), 시뮬레이트 DoS, 시뮬레이트 DDoS
  • 포트 플러딩
  • 프로토콜 플러딩
  • 요청 플러딩(로그인 요청 플러딩, API 요청 플러딩)

GuardDuty

GuardDuty는 AWS CloudTrail, Amazon VPC 흐름 로그 및 DNS 로그와 같은 여러 AWS 데이터 원본에 걸쳐 수백억 건의 이벤트를 분석 route53 이아니라 외부 ad 흐름은 확인할수 없음.

SecureString

SecureString 파라미터는 안전한 방식으로 저장되고 참조되어야 하는 모든 민감한 데이터를 뜻합니다. 암호나 라이선스 키처럼 사용자가 일반 텍스트로 수정하거나 참조해서는 안 되는 데이터가 있는 경우, SecureString 데이터 형식을 사용하여 이 파라미터를 생성합니다.

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/sysman-paramstore-securestring.html

aws kms additional authenticated data

암호화 컨텍스트

대칭 CMK를 사용하는 모든 AWS KMS 암호화 작업은 데이터에 대한 추가 컨텍스트 정보를 포함할 수 있는 선택적 키–값 페어 세트인 암호화 컨텍스트를 수락합니다. AWS KMS는 암호화 컨텍스트를 추가 인증 정보(AAD)로 사용하여 인증된 암호화를 지원합니다.

s3-403

https://aws.amazon.com/premiumsupport/knowledge-center/s3-troubleshoot-403/

kms-버킷정책-역할의 iam 권한

AWS 리소스에 대한 액세스를 타사에 부여할 때 외부 ID를 사용하는 방법

이따금 AWS 리소스에 대한 액세스를 타사에 부여해야 할 때가 있습니다(액세스 위임). 이 시나리오의 한 가지 중요한 부분은 IAM 역할 신뢰 정책에서 역할 수임자를 지정하는 데 사용할 수 있는 옵션 정보인 외부 ID입니다.

sts:Externald

wordprss-smart-qoute disable

지금까지 내블로그는 복붙이면 가능하도록 만들어 졌다고 생각했다.

그런데 따라해보니 시작부터 에러가 발생하였다.

뭐지? 하고 보니 json 에서 쿼터가..

wordpress smart quotes disable에 대한 이미지 검색결과

이런식으로 작동하는거였다.

이페이지를 참고하여 /wordpress/wp-content/plugins 경로에 disable-plugin-quotes.php 를 생성하고 아래와 같은 내용을 추가하여 주었다.

[root@ip-10-0-0-12 plugins]# cat disable-plugin-quotes.php
<?PHP
/*
Plugin Name: Disable Smart Quotes
Plugin URI: http://www.fayazmiraz.com/disable-auto-curly-quotes-in-wordpress/
Description: WordPress Plugin to Disable auto Smart (Curly) quote conversion
Version: 1.0
Author: Fayaz Ahmed
Author URI: http://www.fayazmiraz.com/
*/
if( version_compare ( $wp_version, '4.0' ) === -1 ) {
// To Disable Smart Quotes for WordPress less than 4.0
foreach( array(
'bloginfo',
'the_content',
'the_excerpt',
'the_title',
'comment_text',
'comment_author',
'link_name',
'link_description',
'link_notes',
'list_cats',
'nav_menu_attr_title',
'nav_menu_description',
'single_post_title',
'single_cat_title',
'single_tag_title',
'single_month_title',
'term_description',
'term_name',
'widget_title',
'wp_title'
) as $sQuote_disable_for )
remove_filter( $sQuote_disable_for, 'wptexturize' );
}
else {
// To Disable Smart Quotes for WordPress 4.0 or higher
add_filter( 'run_wptexturize', '__return_false' );
}

이렇게 플러그인이 생성되고 활성화하면

이증상이 사라진다..

지금까지 내블로그에서 복붙안되셨던 분들께 사죄를..

IT infra user group MeetUp review

사진 설명이 없습니다.

IT인프라 유저그룹에서 세션을 진행했습니다.

아무도 이야기하지 않는 클라우드 3사 솔직 비교 라는 주제였습니다.

많은 고민을 해왔던 주제고 어느정도 결론을 낸 주제이므로 나름의 자신이 있었습니다.

글을 써내려 갈때 주로 선택하는 방식이 주제와 결론을 정하고 주제에 따른 살을 입혀서 내용을 풍성하게 만드는 방식으로 주로 글을 씁니다.

퍼블릭 클라우드 3사 비교라는 주제는 자칫하면 쏠릴 수 있고 민감한 주제라 어떻게 풀어가야할지 고민을 많이했지만 평소 관심이 많은 주제라 망설임 없이 슬라이드를 작성하였습니다.

가장 신경을 쓴부분은 나의 이야기가 상대방이 공감할수 있는이야기 인가? 이부분을 최대한 고민해서 작성했습니다.

사실 결론까지 이어지는 맥이 좀 약하다 생각했습니다.

사람들이 내 결론을 잘 받아들였을까 고민될정도...

하지만 결론에 대해 갸웃? 하더라도 전달하고 싶었던 정보들은 내가 가졌던 의구심과 답답했던 과정들은 가감없이 전달될것이라 생각했기 때문에 내 불편함에 대해서 사람들이 공감할수 있다면 절반은 성공이라 생각하며 슬라이드를 작성하였습니다.

"어떤 클라우드가 싸고 좋은가요? " 이 뻔 하고 어려운 질문에 답변을 하는게 이번 세션에서 말하고 싶은 바였습니다.

그래서 저의 결론은 "더 좋고 더 나쁜 클라우드는 없다." 였습니다.

역할에 따라 취향에 따라 상황에 따라 비용에 따라 모든것은 인프라일 뿐 그저 맞춰서 사용하는것이 정답이라는 대답을 드릴수 밖에 없었습니다. 정말로 교과서 적인 대답이지만 이 답변을 드리기 위해 경험한 바를 풀어가며 살을 붙였습니다.

여러 고민 끝에 슬라이드를 작성하였고 23일 meetup에서 세션을 진행하였습니다.

긴장이 되긴 했는데 딱 적당한 긴장감이었고 처음하는 세션이라 중간중간 방향성을 잃긴 했지만 결국 방향성을 되찾았습니다.

눈을 가린 말처럼 슬라이드의 마지막장으로 달려갔습니다.

준비한 멘트는 많았지만 생각만큼 조리있게 설명하는건 쉽지 않았습니다.

말은 뇌를 거치지 않은게 더 많았습니다.

고심해서 하는 말보단 날것의 멘트가 점점 차오를 쯤 슬라이드의 마지막장에 이르렀습니다.

어려운 질문일수록 더욱 깊게 생각납니다.

"멀티클라우드 구성 관련 질문을 주셨는데 벤더락을 피하고 싶다." 라는 질문을 하셨습니다. 저는 개인적으로 아직까진 멀티 클라우드에 대해서 부정적인 입장입니다.

떨어뜨릴수 있는 서비스라면 분리해야한다 생각합니다.

이유는 비용과 트래픽의 측면을 제외 할 수 없습니다. 각 퍼블릭 클라우드의 장점인 서비스만 떼서 이용 할 수 있다면 더 할 나위없이 좋겠지만 컨셉이 정해지기 전까진 정말 답이없는 이야기라 생각이 됩니다.

어제의 세션을 저스스로 점수를 메기자면 7점 정도를 주려고 합니다.

저는 처음이었고 연초부터 쉼없이 달려왔습니다.
좀 지친 상태에서 시작했지만 즐겁게 준비했고 의도한 바는 전달한거 같습니다.

짧은 시간 준비한 세션이었고 만족하지 못한 분이 계실수도 있다 생각합니다.

이부분은 제가 따로 채우겠습니다. 궁금하신 부분이나 이상한 부분이 있다면 언제든 질문해 주세요. 답변드리겠습니다.

즐거운 세션이었고 좋은분들과 함께 해서 의미있었습니다.

먼저 흔히 할수 없는 기회를 주신 조훈님께 감사드립니다.

글읽어 주신 분들. 세션을 봐주신 분들께 감사인사를 드립니다.

마지막으로 감사합니다.

발표에 사용한 슬라이드를 첨부합니다.

gmail-mail-delete

구글메일의 용량이 가득차 문제가 생기는 경우가 있으실 겁니다.

size:100k older_than:1y -@gmail.com

100K 이상 1년 이상 위의 @gmail.com 메일주소를 제외하고 검색해주는 명령어 입니다.

google 검색 규칙과도 동일하므로 패턴을 좀더 확실하게 알고싶으시면

https://support.google.com/vault/answer/2474474?hl=ko

다음 URL 을 참고하세요.

aws-linuxer의 블로그 톺아보기

그 동안 블로그를 운영하면서 블로그에 이것저것 적용해 보느라 시간 가는줄 몰랐다.

대략적인 블로그의 구성도를 그려보았고 구성도를 하나하나 풀어보는 시간을 가져보려한다.

먼저 내블로그는 apm 으로 이루어진 상태였다. 프리티어로 도메인도 없는 상태였고 그냥 테스트 용도 였다.

그 블로그를 먼저 rds 로 분리를 진행 했다.

인스턴스한대에 apache + php + mariadb 였던 구성에서 mariadb 를 rds 로 옮겼다.
그리고 php를 php-fpm 으로 교체 했다.

이시기엔 그냥 구성만 진행하려던 시기라 뭔가 많이 붙이지 않았다. 이 다음 과정에서 로드벨런서를 붙였다.

ALB를 붙이고 나서 letsencrypt 로 인증서를 붙일가 구매를 할까 고민을 하였으나 결국 ACM을 사용하였다.

ALB는 여러개의 인증서를 사용할수 있고 ACM 은 한개의 인증서당 여러개의 도메인을 넣을수있다. 나는 linuxer.name / *.linuxer.name 루트도메인과 와일드카드로 이루어진 두개의 도메인을 acm으로 사용하고 있다.

이다음 진행한 설정을 s3 upload 다.

s3로 이미지를 업로드하고 cloudfront 로 응답한다. 블로그의 응답속도가 굉장히 올라갔다.

cdn.linuxer.name 도메인은 acm 을이용하는데 버지니아 북부에 acm을 설정해야 한다.

업로드 설정을 마친 다음에는 HA를 구성해 보았다. 이과정에서 redis 나 세션을 공유하기 위한 고민을 하였는데 사실 로그인은 나만해서 의미가 없었다. 또한 upload 도 s3로 해서 그냥 정말로 인스턴스만 만들고 대상그룹에 추가만 하면 바로 multi zone 구성이 바로 되었다. 단순한 wp! 칭찬해

그다음엔 지금도 수시로 테스트위해서 켜고 끄는RDS의 multiaz 진짜 고가용성을 위해선 아니고 그냥....썼다.

이부분은 두가지 이유떄문에 설정을 진행했는데, 먼저 중국의 해커가 너무 접근이 많았다. 또한 블로그에 매일 비아그라 광고가 봇도아니고 손으로 직접올리는 사림이 있었다. IP는 신기하게 매번 조금씩 달랐지만 댓글을 좀 지우다가 귀찮아서 결국 국가 차단을 계획했다.

지오로케이션을 지용하여 중국과 스패머의 국가를 Null 로 라우팅 하였다.

중국과 스패머의 국가 이외엔 cloudfront 로 접근된다.
일반적인 캐싱이나 CDN이 아니라 dynamic cdn 방식이다. 조금이라도 ALB로 빨리 접근하기 위한 방법이나 ...효과는 잘...아마 한국이라 그럴거다.

cf 는 버지니아 북부의 acm을 이용하여 도메인을 인증하고 인증된 도메인은 waf 연결된다. waf는 서울리전의 alb에 연결되어있다.

유저는 그럼 route53을통해 cf에 연결되어 waf 를 통과하고 alb에 연결되어 web ec2에 연결되고 rds의 데이터를 읽어서 페이지를 볼수있는거다.

생각보다 설명이 길었는데..아무튼 뭔가 많다.

대략적인 블로그의 구성도를 그리고 역할을 설명하였다.

내블로그지만 나름 재미있게 가꾼거 같다.

즐거운 저녁되시라!

aws-route53-review

요 며칠간 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/

내용을 확인해 보면 신뢰할수 있는 응답에 ipv4-ipv6를 응답하게 되어있다고 나와있다.

따라서..alias는 문제가 없었다.

그렇다면 문제가 있었을 cf는 무엇일까?

cname 을 사용하던 도메인들이다.

cname을 설정하면 이렇다.

>test2.linuxer.name
서버: UnKnown
Address: 210.219.173.151
권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2150:1a00:10:3683:b8c0:93a1
2600:9000:2150:8000:10:3683:b8c0:93a1
2600:9000:2150:c000:10:3683:b8c0:93a1
2600:9000:2150:6400:10:3683:b8c0:93a1
2600:9000:2150:8c00:10:3683:b8c0:93a1
2600:9000:2150:1000:10:3683:b8c0:93a1
2600:9000:2150:7800:10:3683:b8c0:93a1
2600:9000:2150:e200:10:3683:b8c0:93a1
52.85.231.10
52.85.231.111
52.85.231.68
52.85.231.42
Aliases: test2.linuxer.name

ipv6 와 ipv4를 모두응답한다. 이 경우 ipv6가 우선라우팅이 된다.

그래서 결국 route53 공식문서를 확인해보니 A/AAAA를 같이쓰라고 되어있다.

cloudfront 는 cname 을 제공하고 A record를 사용할경우 cloudfront 의 IP변경에 대응할수 없다. 그렇기 때문에 일반적으로 A alias 를 사용하라 한것이다.

명시적인 레코드의 분리를 뜻하는 것이다. 일반적으로 잘 발생하는 문제는 아닌것으로 보이나, cname 을 사용하게되면 이렇다.

일반적으로 도메인에 요청을 할때 레코드를 지정해서 쿼리하진 않는다.
그래서 cname 으로 요청하게되면 cname 에 연결된 모든 record가 응답하게 되고 그 결과 값에 따라서 ipv6 가 존재하면 ipv6 로 라우팅 된다.

nslookup 결과
>test2.linuxer.name
서버: dns.google
Address: 8.8.8.8권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2139:e200:10:3683:b8c0:93a1
2600:9000:2139:fa00:10:3683:b8c0:93a1
2600:9000:2139:4c00:10:3683:b8c0:93a1
2600:9000:2139:7400:10:3683:b8c0:93a1
2600:9000:2139:5400:10:3683:b8c0:93a1
2600:9000:2139:aa00:10:3683:b8c0:93a1
2600:9000:2139:2600:10:3683:b8c0:93a1
2600:9000:2139:6c00:10:3683:b8c0:93a1
99.86.144.35
99.86.144.128
99.86.144.34
99.86.144.126
Aliases: test2.linuxer.name

따라서 route53을 사용할때 A/AAAA를 분리해서 사용하라는 말이다.

그런데 말입니다.

그런데 말입니다에 대한 이미지 검색결과

A레코드는 쓸수 없잖아? cf는 IP가 바뀌니까..

그래서 결론이 난다. 확실하게 정해준다.

A Alias AAAA alias 를 사용하는걸 권장한다.
같은계정내 자원이라면!

아니라면?

cname 을 사용할수 밖에 없다면 CloudFront 의 IPv6 를 끄자.

CloudFront Distributions > General > Enable IPv6

체크박스만 누르고 Yes, Edit 만 누르면 된다.

참쉽죠.

참곤란한 이슈였다. 참고-URL

https://www.facebook.com/groups/awskrug/permalink/2278291878939490/

https://tools.ietf.org/html/rfc3484?fbclid=IwAR0Ca2JDM55CpyhZSjtiR7EYhySfzADdLMRX2q-rWZoAM-z8BHbqismCQfk#section-2.1

읽어주셔서 감사하다!

호텔 델루나 뱃지 없으니 만든다!

장만월 사장의 호텔 델루나에 취업하고 싶은 찰나 완결이 다와가고 있어서 죽어서 취업할 순 없으니.....마음만이라도 델루나에서 함께하고 싶은 마음에 급하게 모델링을 시작했다.

일단 뚝딱 모델링을 끝내고 첫번째 프린트를 시작했다.

사이즈가 좀 작았다. 2cm 에 높이 1.3 얇게 테스트를 해봤는데 생각보다 깔끔하게 나오긴 했으나.. 원한 느낌은 아니었다. 출력시간 6분

갑자기 결론을 내서 미안하다.

3D 프린터가 고장나서 급하게 고치고 뽑느라 결과물만 있다.

가로세로 2.5cm 높이 2mm로 뽑았다. 0.12mm 노즐로 뽑아서 결이 고르지 못하다.

하지만 첫 완성 작인거 같아 포스팅을 한다.

이상한 주제의 글

필자는 의식의 흐름에 따라서 글을 쓰는것을 아주 잘하는 편이다.

오늘은 주제를 추전받았는데 이상한 주제로 글을쓰라는 추천을 받아서 포스팅을 작성하게 되었다.

이상한 주제라고 하면 결국 치과이야기가 적당할것 같다.

교정 3년차의 프로페셔널 교정러다.

교정이 거의 마무리단계이며 교정과정을 먼저 설명해 보겠다.

일단 엑스레이를 찍어서 견적을 받는다. 300만원으로 견적을 받아서 교정을 시작했다. 교정을 하게 된 이유는 간단하게.. 작은어금니와 어금니 사이에 치아가 삼각꼴을 이루며 덧니로 나게되었다. 이유는 여러가지겠지만 하관이 작아서 치아가 한줄에 다못들어간게 이유라면 이유다.

이 작은송곳니를 뽑았다. 교정시작한 첫날에 뽑았는데 너무 행복했다 덧니사이에 끼는 음식물을 더이상 빼지 않아도 된다는 사실이 너무좋았다.

좋은것은 좋은것이고 너무아팠다.

치아와 모발은 소중한것이니 필자처럼 막뽑지 않는것을 추천한다.

그리고 철길을 깔았다.

1달에 한번씩 치과를 갔다. 치아를 고른 열로 sort 하고 규격에 맞지않는 치아는 뽑았다. 그 규격에 맞지않는 치아가 첫째 작은 어금니이다.

첫 교정하는날 1개 그리고 8개월차쯤에 2개 21개월 차에 1개를 뽑았다.

위아래 작은어금니를 뽑았다 이말이다. 그때부턴가 없어져버린 치아처럼 본인도 위아래가 없어진거 같다.

그렇게 4개의 치아를
root@입안# rm -rf "작은송곳니"
하고 각각 치아마다 철길로 연결되서 가지런하게 배열되었다.

고통의 나날들로 다른사람이 교정한다고 하면 꼭 하라고 할거다. 왜냐고? 나만 아플순 없으니까. 진짜 개아프거든.. 밥먹을때마다 입안이 철사에 찢기고 장치에 베이고..헐고 피가나는건 예사일이다. 느긋하고 성격고치고 싶은 사람은 꼭 교정을 해라 성격베리고 예민해지니까.

말이샛는데 교정은 끝나는게 아니라 유지하는거다.

철길을 뺀다고 교정이 끝나는게 아니라 치아뒷편에 교정을 유지해주는 철사를 평생 붙이고 있어야하고 교정을 유지해주는 유지장치를 일정 기간마다 껴야한다.

아주 귀찮은 일이란 말이다.

그렇기에 추천한다.

필자는 미용상의 이유로 교정을 했다.

거짓말 같겠지만 진짜다.

교정을 하고나니 얼굴 라인이 달라졌다 웃는 모습도 가지런해졌다.

자신감과 신기함에 거울보면서 치아점검을 자주한다.

황니인지라 신경쓰여서 워터픽과 음파칫솔을 애용하는데 이것의 리뷰는 나중에 하고 이상한 주제의 블로깅을 마친다.