[PUBLISHER] upload files #150

* PUSH NOTE : Secure IAM on AWS with Multi-Account Strategy.md

* PUSH ATTACHMENT : separation-by-product.png

_config.yml

@@ -74,7 +74,7 @@ theme_mode: light
 # will be added to all image (site avatar & posts' images) paths starting with '/'
 #
 # e.g. 'https://cdn.com'
-img_cdn:
+img_cdn: "https://blog.zxcvber.com"
 
 # the avatar on sidebar, support local or CORS resources
 avatar: assets/img/avatar.png

_includes/js-selector.html

@@ -89,7 +89,7 @@
         macros: {
           ds: "\\displaystyle",
 
-          // font styles
+          /* font styles */
           rm: ["\\mathrm{#1}", 1],
           mf: ["\\mathfrak{#1}", 1],
           mc: ["\\mathcal{#1}", 1],
@@ -142,7 +142,7 @@
           exists: "∃\\,",
 
           tilde: ["\\widetilde{#1}", 1],
-          hat: ["\\widehat{#1}", 1],
+          hat: ["\\widehat{#1}", 1]
         },
         tags: 'ams'
       }

_posts/Development/2024-02-26-secure-iam.md

@@ -1,5 +1,6 @@
 ---
 share: true
+pin: true
 categories:
   - Development
 tags:
@@ -8,8 +9,40 @@ tags:
 title: Secure IAM on AWS with Multi-Account Strategy
 date: 2024-02-26
 github_title: 2024-02-26-secure-iam
+image: /assets/img/posts/Development/separation-by-product.png
+attachment:
+  folder: assets/img/posts/Development
 ---
 
-B.S. Graduation Paper, Received Best Paper Award!
+![separation-by-product.png](../../assets/img/posts/Development/separation-by-product.png)
 
-- [Paper Link](https://zxcvber.com/secure-iam.pdf)
+2024\. 2. B.S. Graduation Paper, Received Best Paper Award!
+
+- [Secure IAM on AWS with Multi-Account Strategy (pdf)](https://zxcvber.com/files/secure-iam.pdf)
+- [Presentation Poster (pdf)](https://zxcvber.com/files/secure-iam-poster.pdf)
+
+## Abstract
+
+Many recent IT companies use cloud services for deploying their products, mainly because of their convenience. As such, cloud assets have become a new attack surface, and the concept of cloud security has emerged. However, cloud security is not emphasized enough compared to on-premise security, resulting in many insecure cloud architectures. In particular, small organizations often don't have enough human resources to design a secure architecture, leaving them vulnerable to cloud security breaches.
+
+We suggest the multi-account strategy for securing the cloud architecture. This strategy cost-effectively improves security by separating assets and reducing management overheads on the cloud infrastructure. When implemented, it automatically provides access restriction within the boundary of an account and eliminates redundancies in policy management. Since access control is a critical objective for constructing secure architectures, this practical method successfully enhances security even in small companies.
+
+In this paper, we analyze the benefits of multi-accounts compared to single accounts and explain how to deploy multiple accounts effortlessly using the services provided by AWS. Then, we present possible design choices for multi-account structures with a concrete example. Finally, we illustrate two techniques for operational excellence on multi-account structures. We take an incremental approach to secure policy management with the principle of least privilege and introduce methods for auditing multiple accounts.
+
+**Keywords**: multi-account strategy, identity and access management, cloud security
+
+## 국문초록
+
+**제목**: 다중 계정을 이용한 안전한 AWS 권한 관리
+
+최근 많은 IT 기업이 편리하게 자사 제품을 배포하기 위해 클라우드 서비스를 사용한다. 이에 따라 기업의 클라우드 자원은 새로운 공격 표면이 되었고, 클라우드 보안이라는 분야가 새롭게 대두되었다. 그러나 클라우드 보안은 기존의 온프레미스 보안에 비해 충분히 강조되지 못해 보안에 취약한 클라우드 아키텍처를 사용하는 경우가 많다. 특히 작은 조직의 경우 안전한 클라우드 아키텍처를 고안할 인력이 부족한 경우가 많아 클라우드에서 발생하는 보안 사고에 취약한 편이다.
+
+이 상황에서 보안을 손쉽게 강화하려면 다중 계정 환경을 적용하면 된다. 다중 계정 환경은 클라우드의 자원을 분리하고 관리 부하를 줄여 보안을 강화하는 전략으로, 노력 대비 큰 보안 향상을 준다. 이 전략을 적용하면 자동으로 접근 권한이 계정 범위 내로 제한되며, 정책 관리 시 발생하는 불필요한 중복이 제거된다. 안전한 아키텍처를 위해 권한 관리가 필수임을 고려한다면, 다중 계정 환경은 인력이 부족한 작은 조직에서도 적용할 수 있는 효과적인 보안 강화 방법이다.
+
+이 논문에서는 다중 계정 환경의 장점을 단일 계정 환경과 비교하여 분석하고, AWS가 제공하는 서비스를 이용해 다중 계정 환경을 손쉽게 구성하는 방법을 설명한다. 또한 다중 계정 구조의 구체적인 예시를 통해 계정 구조 설계 시 유의할 점들을 언급한다. 마지막으로 최소 권한 원칙의 점진적 도입을 통한 안전한 정책 관리 방법과 다중 계정의 감사 방법을 소개하여 다중 계정 구조에서 운영 효율성을 달성하는 방법을 설명한다.
+
+**주요어**: 다중 계정 환경, 권한 및 접근 제어, 클라우드 보안
+
+## Acknowledgements
+
+Special thanks to Professor Chung-Kil Hur for advising my paper, and to Professor Yongsoo Song for his recommendation for the best paper award.

_posts/Lecture Notes/Internet Security/2023-09-10-security-intro.md

@@ -155,7 +155,7 @@ There are many ways of achieving security.
 
 ### Basics of a Cryptosystem
 
-![is-01-cryptosystem.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-01-cryptosystem.png#)
+![is-01-cryptosystem.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-01-cryptosystem.png)
 
 - A **message** in *plaintext* is given to an **encryption algorithm**.
 - The encryption algorithm uses an **encryption key** to create a *ciphertext*.

_posts/Lecture Notes/Internet Security/2023-09-18-symmetric-key-cryptography-2.md

@@ -63,7 +63,7 @@ $$
 
 #### The Feistel Function
 
-![is-03-feistel-function.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-feistel-function.png#)
+![is-03-feistel-function.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-feistel-function.png)
 
 The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using a P-box. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a (straight) permutation at the end, resulting in $32$ bit data.
 
@@ -179,7 +179,7 @@ AES, DES use fixed block size for encryption. How do we encrypt longer messages?
 
 ### Electronic Codebook Mode (ECB)
 
-![is-03-ecb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ecb-encryption.png#)
+![is-03-ecb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ecb-encryption.png)
 
 - Codebook is a mapping table.
 - For the $i$-th plaintext block, we use key $k$ to encrypt and obtain the $i$-th ciphertext block.
@@ -198,7 +198,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 
 ### Cipher Block Chaining Mode (CBC)
 
-![is-03-cbc-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cbc-encryption.png#)
+![is-03-cbc-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cbc-encryption.png)
 
 - Two identical messages produce to different ciphertexts.
 	- This prevents chosen plaintext attacks
@@ -248,7 +248,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 
 ### Cipher Feedback Mode (CFB)
 
-![is-03-cfb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cfb-encryption.png#)
+![is-03-cfb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cfb-encryption.png)
 
 - The message is treated as a stream of bits; similar to stream cipher
 - **Result of the encryption is fed to the next stage.**
@@ -283,7 +283,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 
 ### Output Feedback Mode (OFB)
 
-![is-03-ofb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ofb-encryption.png#)
+![is-03-ofb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ofb-encryption.png)
 
 - Very similar to stream cipher.
 - Initialization vector is used as a seed to generate the key stream.
@@ -316,7 +316,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 
 ### Counter Mode (CTR)
 
-![is-03-ctr-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ctr-encryption.png#)
+![is-03-ctr-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ctr-encryption.png)
 
 - Without chaining, we use a counter (typically incremented by $1$).
 	- Counter starts from the initialization vector.

_posts/Lecture Notes/Internet Security/2023-10-16-pki.md

@@ -83,7 +83,7 @@ We have a root CA at the top. Then there are issuing CAs below. We usually reque
 
 ### Certificate Validation
 
-![is-08-certificate-validation.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-08-certificate-validation.png#)[^1]
+![is-08-certificate-validation.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-08-certificate-validation.png)[^1]
 
 Since we have a hierarchy of CAs, certificate validation must also follow the hierarchy. When we receive a certificate, it is highly likely to be signed by an non-root CA.
 

_posts/Lecture Notes/Internet Security/2023-10-18-tls.md

@@ -146,7 +146,7 @@ Here's how the client and the server establishes a connection using the TLS hand
 > 3. Use the server's public key to share a secret.
 > 4. Both parties generate a symmetric key from the shared secret.
 
-![is-09-tls-handshake.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-09-tls-handshake.png#)[^1]
+![is-09-tls-handshake.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-09-tls-handshake.png)[^1]
 
 - `ServerKeyExchange`, `ClientKeyExchange` is optional. Used sometimes if Diffie-Hellman is used.
 - The actual messages and process differ for each protocol and ciphers used.

_posts/Lecture Notes/Modern Cryptography/2023-09-07-otp-stream-cipher-prgs.md

@@ -292,7 +292,7 @@ We can deduce that if a PRG is predictable, then it is insecure.
 
 *Proof*. Let $\mathcal{A}$ be an efficient adversary (next bit predictor) that predicts $G$. Suppose that $i$ is the index chosen by $\mathcal{A}$. With $\mathcal{A}$, we construct a statistical test $\mathcal{B}$ such that $\mathrm{Adv}_\mathrm{PRG}[\mathcal{B}, G]$ is non-negligible.
 
-![mc-01-prg-game.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-prg-game.png#)
+![mc-01-prg-game.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-prg-game.png)
 
 1. The challenger PRG will send a bit string $x$ to $\mathcal{B}$.
 	- In experiment $0$, PRG gives pseudorandom string $G(k)$.
@@ -318,7 +318,7 @@ The theorem implies that if next bit predictors cannot distinguish $G$ from true
 
 To motivate the definition of semantic security, we consider a **security game framework** (attack game) between a **challenger** (ex. the creator of some cryptographic scheme) and an **adversary** $\mathcal{A}$ (ex. attacker of the scheme).
 
-![mc-01-ss.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-ss.png#)
+![mc-01-ss.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-ss.png)
 
 > **Definition.** Let $\mathcal{E} = (G, E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. For a given adversary $\mathcal{A}$, we define two experiments $0$ and $1$. For $b \in \lbrace 0, 1 \rbrace$, define experiment $b$ as follows:
 > 

_posts/Lecture Notes/Modern Cryptography/2023-09-19-symmetric-key-encryption.md

@@ -131,7 +131,7 @@ Additional explanation available in [Modes of Operations (Internet Security)](..
 
 ### Electronic Codebook Mode (ECB)
 
-![is-03-ecb-encryption.png](/assets/img/posts/is-03-ecb-encryption.png#)
+![is-03-ecb-encryption.png](/assets/img/posts/is-03-ecb-encryption.png)
 
 - ECB mode encrypts each block with the same key.
 - Blocks are independent of each other.
@@ -139,7 +139,7 @@ Additional explanation available in [Modes of Operations (Internet Security)](..
 
 ### Ciphertext Block Chain Mode (CBC)
 
-![is-03-cbc-encryption.png](/assets/img/posts/is-03-cbc-encryption.png#)
+![is-03-cbc-encryption.png](/assets/img/posts/is-03-cbc-encryption.png)
 
 Let $X = \left\lbrace 0, 1 \right\rbrace^n$ and $E : \mathcal{K} \times X \rightarrow X$ be a **PRP**.
 
@@ -190,7 +190,7 @@ Note that if $k_1$ is the same as the key used for encrypting messages, then thi
 
 ### Counter Mode (CTR)
 
-![is-03-ctr-encryption.png](/assets/img/posts/is-03-ctr-encryption.png#)
+![is-03-ctr-encryption.png](/assets/img/posts/is-03-ctr-encryption.png)
 
 Let $F : \mathcal{K} \times X \rightarrow X$ be a secure **PRF**.
 

_posts/Lecture Notes/Modern Cryptography/2023-09-26-cca-security-authenticated-encryption.md

@@ -83,7 +83,7 @@ The attacker shouldn't be able to create a new ciphertext that decrypts properly
 
 In this case, we fix the decryption algorithm so that $D : \mathcal{K} \times \mathcal{C} \rightarrow \mathcal{M} \cup \left\lbrace \bot \right\rbrace$, where $\bot$ means that the ciphertext was rejected.
 
-![mc-05-ci.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-ci.png#)
+![mc-05-ci.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-ci.png)
 
 > **Definition.** Let $\mathcal{E} = (E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. Given an adversary $\mathcal{A}$, the security game goes as follows.
 > 
@@ -138,7 +138,7 @@ Most natural constructions of CCA secure schemes satisfy AE, so we don't need to
 
 We want to combine CPA secure scheme and strongly secure MAC to get AE. Rather than focusing on the internal structure of the scheme, we want a general method to compose these two secure schemes so that we can get a AE secure scheme. We will see 3 examples.
 
-![mc-05-etm-mte.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-etm-mte.png#)
+![mc-05-etm-mte.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-etm-mte.png)
 
 ### Encrypt-and-MAC (E&M)
 

_posts/Lecture Notes/Modern Cryptography/2023-09-28-hash-functions.md

@@ -106,7 +106,7 @@ Now we want to construct collision resistant hash functions that work for arbitr
 
 The Merkle-Damgård transform gives as a way to extend our input domain of the hash function by iterating the function.
 
-![mc-06-merkle-damgard.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-merkle-damgard.png#)
+![mc-06-merkle-damgard.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-merkle-damgard.png)
 
 > **Definition.** Let $h : \left\lbrace 0, 1 \right\rbrace^n \times \left\lbrace 0, 1 \right\rbrace^l \rightarrow \left\lbrace 0, 1 \right\rbrace^n$ be a hash function. The **Merkle-Damgård function derived from $h$** is a function $H$ that works as follows.
 > 
@@ -151,7 +151,7 @@ Now we only have to build a collision resistant compression function. We can bui
 
 Number theoretic primitives will be shown after we learn some number theory.[^3] An example is shown in [collision resistance using DL problem (Modern Cryptography)](../2023-10-03-key-exchange#collision-resistance-based-on-dl-problem).
 
-![mc-06-davies-meyer.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-davies-meyer.png#)
+![mc-06-davies-meyer.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-davies-meyer.png)
 
 > **Definition.** Let $\mathcal{E} = (E, D)$ be a block cipher over $(\mathcal{K}, X, X)$ where $X = \left\lbrace 0, 1 \right\rbrace^n$. The **Davies-Meyer compression function derived from $E$** maps inputs in $X \times \mathcal{K}$ to outputs in $X$, defined as follows.
 > 
@@ -216,7 +216,7 @@ This can be thought of as blocking the length extension attack from prepending t
 
 ### HMAC
 
-![mc-06-hmac.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-hmac.png#)
+![mc-06-hmac.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-hmac.png)
 
 This is a variant of the two-key nest, but the difference is that the keys $k_1', k_2'$ are not independent. Choose a key $k \leftarrow \mathcal{K}$, and set
 

_posts/Lecture Notes/Modern Cryptography/2023-10-03-key-exchange.md

@@ -74,7 +74,7 @@ $$
 
 We assume that the description of $p$, $q$ and $g$ are generated at the setup and shared by all parties. Now the actual protocol goes like this.
 
-![mc-07-dhke.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke.png#)
+![mc-07-dhke.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke.png)
 
 > 1. Alice chooses $\alpha \leftarrow \mathbb{Z}_q$ and computes $g^\alpha$.
 > 2. Bob chooses $\beta \leftarrow \mathbb{Z}_q$ and computes $g^\beta$.
@@ -189,7 +189,7 @@ Taking $\mathcal{O}(N)$ steps is impractical in the real world, due to many comm
 
 We assumed that the adversary only eavesdrops, but if the adversary carries out active attacks, then DHKE is not enough. The major problem is the lack of **authentication**. Alice and Bob are exchanging keys, but they both cannot be sure that there are in fact communicating with the other. An attacker can intercept messages and impersonate Alice or Bob. This attack is called a **man in the middle attack**, and this attack works on any key exchange protocol that lacks authentication.
 
-![mc-07-dhke-mitm.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke-mitm.png#)
+![mc-07-dhke-mitm.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke-mitm.png)
 
 The adversary will impersonate Bob when communicating with Alice, and will do the same for Bob by pretending to be Alice. The values of $\alpha, \beta$ that Alice and Bob chose are not leaked, but the adversary can decrypt anything in the middle and obtain the plaintext.
 
@@ -211,7 +211,7 @@ Before Diffie-Hellman, Merkle proposed an idea for secure key exchange protocol
 
 The idea was to use *puzzles*, which are problems that can be solved with some effort.
 
-![mc-07-merkle-puzzles.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-merkle-puzzles.png#)
+![mc-07-merkle-puzzles.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-merkle-puzzles.png)
 
 > Let $\mathcal{E} = (E, D)$ be a block cipher defined over $(\mathcal{K}, \mathcal{M})$.
 > 1. Alice chooses random pairs $(k_i, s_i) \leftarrow \mathcal{K} \times \mathcal{M}$ for $i = 1, \dots, L$.