AWS IAM 정책은 권한 에스컬레이션을 허용하지 않아야 합니다.
AWS IAM(신원 및 액세스 관리)은 AWS 리소스에 대한 액세스를 정의하는 서비스입니다.
IAM의 핵심 구성 요소 중 하나는 ID 또는 리소스에 연결될 때 해당 권한을 정의하는 정책입니다.
아이덴티티(사용자, 그룹 또는 역할)에 권한을 부여하는 정책을 아이덴티티 기반 정책이라고 합니다.
이러한 정책은 리소스 목록에 대해 미리 정의된 일련의 작업을 수행할 수 있는 기능을 ID에 추가합니다.
다음은 사용자에게 자신의 액세스 키를 관리할 수 있는 기능을 부여하는 제한된 권한 집합을 정의하는 정책 문서의 예입니다.
{
"Version": "2012-10-17",
"Statement": [
{
...
JWT에 서명하고 검증해야 합니다.
강력한 암호 알고리즘으로 서명되지 않았거나 전혀 서명되지 않은 경우 공격자는 JSON 웹 토큰(JWT)을 위조하여 사용자 신원을 사칭할 수 있습니다.
토큰의 유효성을 서명하거나 검증하는데 아무 알고리즘도 사용하지 마세요.
이전에 서명을 검증하지 않은 토큰은 사용하지 마세요.
규칙을 어긴 코드
For pyjwt module:
jwt.decode(token, verify = False) # 규칙을 어긴 코드
jwt.decode(token, key, options={"verify_signature": False}) # 규칙을 어긴 코드
For python_jwt module:
jwt.process_jwt(tok...
암호 알고리즘은 강력해야 합니다.
강력한 암호 알고리즘은 암호 분석에 강한 암호화 시스템으로, 예를 들어 무차별 암호 대입 공격과 같은 잘 알려진 공격에 취약하지 않습니다.
일반적으로 암호화 커뮤니티에서 집중적으로 테스트하고 홍보하는 암호화 알고리즘만 사용할 것을 권장합니다.
특히 블록 암호의 경우 블록 크기가 128비트보다 작은 알고리즘은 사용하지 않는 것이 좋습니다.
규칙을 어긴 코드
pycryptodomex 라이브러리:
from Cryptodome.Cipher import DES, DES3, ARC2, ARC4, Blowfish, AES
from Cryptodome.Random import get_random_bytes
key = b'...
변수들은 서로 관계가 없기 전에는 선언되어서는 안됩니다.
명확성을 위해서는, 변수들은 변수들이 사용되는 곳과 가능한 가까운 곳에서 선언되어야 합니다.
이것은 특히 메소드가 조기 반환(early return)하거나, 잠재적으로 예외를 throw 할 가능성이 있을 때 특히 그렇습니다.
이러한 경우, 조기 반환이 먼저 만족되어 절대 사용되지 않을 변수를 선언하는 것은 의미없을 뿐 아니라 혼란스럽습니다.
규칙을 어긴 코드
public boolean isConditionMet(int a, int b) {
int difference = a - b;
MyClass foo = new MyClass(a); // 규칙을 어긴 코드; 조기 반환 이전에 사용되지 않습니다....
3항 연산자는 사용하지 않아야 합니다.
삼항 연산자가 보기 좋게 간결하지만, 이를 사용하면 코드를 더 읽기 어렵게 만들 수 있습니다. 그러므로 이를 피하고, 보다 상세한 if-else 구문을 사용하는 것이 좋습니다.
규칙을 어긴 코드
System.out.println(i > 10 ? "yes" : "no");
규칙을 준수한 해결책
if(i > 10) {
System.out.println(("yes");
} else {
System.out.println("no");
}
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
클래스는 너무 많은 메소드를 가져서는 안됩니다.
과도하게 커지는 클래스는 너무 많은 책임을 결합하려는 경향이 있으며, 그로 인해 필연적으로 이해하거나 유지보수 하기 어렵게됩니다.
특정 임계값을 초과하는 클래스에 대해 더 잘 정의된 도메인에 초점을 맞춘 작은 클래스들로 리팩토링하는 것이 좋습니다.
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
메소드는 너무 많은 코드 라인을 가져서는 안됩니다.
과도하게 커지는 메서드는 너무 많은 책임을 결합하려는 경향이 있습니다. 이러한 메소드들은 필연적으로 이해하거나 유지보수 하기 어렵게됩니다.
특정한 임계치를 초과한 메소드에 대해 더 작은 책임을 가지는 작은 메소드들로 리팩토링하는 것이 좋습니다. 이러한 작은 메소드들은 이해하기 쉬울 뿐만 아니라 테스트하기도 쉬워지게 됩니다.
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
클래스들은 너무 많은 클래스들과 결합되어서는 안됩니다.(단일 책임 원칙)
Robert C. Martin 의 저서 “Principles of Object Oriented Design” 에서 소개된 단일 책임 원칙에 따르면, 클래스는 단 하나의 책임만을 가져야 합니다.
클래스에 둘 이상의 책임이 있는 경우, 책임은 결합됩니다.
하나의 책임을 변경하는 것이 클래스가 다른 책임을 충족시키는 것을 손상시키거나 억제할 수 있습니다.
이러한 커플링은 코드가 수정될 때 예상치 못하게 망가지는 깨지기 쉬운 디자인을 초래할 수 있습니다.
다른 클래스에 너무 많이 의존하는 클래스들은 너무 많은 책임을 결합하려는 경향이 있고, 이 클래스들은 더 작은 클래스들로 분할되어야 합니다.
중첩 클래스 의존...
전체 글 239개, 30 페이지