BlakStar

[0]

AWS나 Google Cloud Platform 등의 클라우드 컴퓨팅은 이미 굉장히 보편화되어 있다. 이런 서비스들은 보안 측면에서 본질적인 한계가 존재하는데, 바로 클라우드 제공사(아마존, 구글 등)들이 사용자들의 데이터를 볼 수 있다는 점이다. 따라서 이들을 신뢰할 수 없다면 당연히 민감한 데이터가 유출될 가능성을 생각할 수밖에 없으므로, 클라우드 컴퓨팅을 이용할 수 없다. 암호화를 사용하면 되는 것 아니냐라고 할 수 있겠지만, 암호화는 저장중/전송중인 데이터만 보호할 수 있다. 런타임에는 코드 건 데이터 건 반드시 메모리 상에 decrypt된 상태로 올라가야 하고, 클라우드 제공사들은 당연히 여기에 접근이 가능하다. 이에 대한 해결책으로 제시되는 것이 하드웨어적인 지원을 더한 confidential computing이다.

[1]

confidential computing은 trusted execution environment(TEE)를 제공한다. 하지만 모든 실행 영역을 TE

E에서 제공할 수 없으므로(하드웨어적인 제약도 있지만 이럴 경우 하이퍼바이저나 커널 등 코드의 모든 stack을 제공해야 한다!) 어플리케이션을 trusted code와 untrusted code로 나눈다. trusted code는 Enclave라고 불리는 독립된 실행 영역을 보장한다. Enclave는 하드웨어적으로 예약된 메모리를 제공받으며, 전용 명령어 셋을 사용하여 data encrption/decryption을 수행한다. 또한 untrusted code와 통신하기 위한 Encalve call / user call이 제공되며, 역시 하드웨어 전용 명령어 셋으로 수행된다. 하드웨어 단에서 명령어를 제공하기 때문에, 소프트웨어적인 encrypt/decrypt보다 performance overhead가 훨씬 작게 된다. 물론 그럼에도 overhead가 상당하기 때문에, trusted code 영역을 최대한 줄이고자 하는 프로그래머의 노력이 필요하다. 

[2] 

Enclave 메모리 영역은 untrusted code에서 접근이 불가능하다. 설령 메모리를 물리적으로 직접 뜯어보더라도(cold boot attack) 암호화되어 있으므로 컨텐츠를 알아낼 수 없다. 여기에서 untrusted code에 대한 정의가 중요한데, 이는 Enclave를 제외한 모든 코드이다. 즉 privilege가 높은 OS나 hypervisor도 untrusted code로 취급되며, Enclave에 직접 접근이 불가능하다! OS 혹은 hypervisor에서 취약점이 발생하여 공격자가 마음껏 privilege를 획득할 수 있다고 하더라도, Enclave를 보호할 수 있다. 따라서 Enclave 코드 자체에 취약점이 존재하지 않는다면, Enclave의 security를 보장할 수 있다. 즉 공격자의 attack surface가 훨씬 줄어들게 되며, 개발자 입장에선 작은 trusted code만 신경 쓰면 되기 때문에 보안성이 훨씬 더 향상된다. (다만 최근에는 Enclave을 공격할 수 있는 side channel attack 논문들이 나와있긴 하다...)

물론 DDoS는 가능하긴 하지만 이건 의미가 없는게, rmsid 클라우드 제공사에서 서버를 꺼버리면 당연히 해당 클라우드 컴퓨팅 서비스도 모두 이용 불가능하기 때문이다. 이 부분에 대해 제공사를 신뢰하는 건 무슨 짓을 해도 불가피하다. 

[참고]

https://www.fortanix.com/blog/2019/07/why-are-enclaves-taking-over-security-world/

https://www.computerweekly.com/blog/Open-Source-Insider/What-is-confidential-computing

418쪽

20.02.08 ~ 03.18 (40일)

'악의 평범성'이라는 부제로 유명한 아이히만의 재판과정을 다룬 철학자 한나 아보트의 레포트. 주제 자체는 굉장히 흥미롭지만, 책의 너무 길고, 이것저것 곁다링 이야기가 너무 많아 읽기 쉽지 않다. 조금 더 흥미롭게 쓸 수 있었을 것 같은데 아쉽다. 여러모로 저자가 기록으로서 출판한 것 같다.

[0]

Rust는 객체 지향적인 언어 특성을 일부 갖고 있지만, 다른 객체 지향 언어와는 차이점도 상당히 많다. 그중 하나가 rust에서는 c++/java의 클래스처럼 코드를 포함하는 object가 존재하지 않는다는 것이다. 대신, Rust에서는 impl구문을 토해 struct 혹은 enum에 대한 메소드를 구현할 수 있다. impl 구문을 통해 trait을 구현하는 것도 가능한데, 이를 통해, Rust는 다형성(polymorphism)을 지원한다. 이글에선 trait에 대해 알아본다.

[1]

trait의 정의는 다음과 같이 할 수 있다.

// code from : https://doc.rust-lang.org/book
pub trait Summary {
    fn summarize(&self) -> String;
}

trait은 다음과 같이 특정 struct 혹은 enum에 대해 구현할 수 있다.

// code from : https://doc.rust-lang.org/book
pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

또한 아래와 같이 default 구현을 만들어 놓을 수 있다. default를 그대로 사용하고자 한다면, impl 구문의 {]를 비워 두면 된다.

// code from : https://doc.rust-lang.org/book
pub trait Summary {
    fn summarize(&self) -> String {
        String::from("(Read more...)")
    }
}

//default implementation of Summary trait would be applied to tweet
impl tweet for Summary {}

이 외에도 다양한 활용법이 있지만, 가장 기본적인 활용은 위의 2가지라고 보면 된다. trait을 이용해서, 코드 중복을 피하면서, 가독성을 높이고 객체지향적인 프로그래밍을 할 수 있게 된다. trait의 조금 더 다양한 활용법은 공식 가이드를 참고하자.

[2]

Rust의 대부분의 기능과 마찬가지로, trait로 컴파일 타임에 구현된다. 컴파일 타임에 하나의 trait에 대해 어떤 타입으로 구현되어야 하는지 미리 알 수 있기 때문에, 실제 사용되는 타입들에 대한 trait만 컴파일 타임에 생성된다. 따라서 런타임 오버헤드가 존재하지 않는다.

[2]

 trait의 java 등의 언어의 interface와 상당히 유사하다. 하지만 디자인 철학적인 부분에서 차이가 있는데, 다음의 사례를 통해 알아보자.

예컨대, animal interface에 move(), eat() 등의 메소드가 구현되어 있다고 생각하자. 이때, robot과 dog 클래스가 있을 경우, dog는 animal 이므로(dog is a animal) 상속받아서 구현하는데 아무런 문제가 없다. 하지만 robot은 animal이 아니고, eat()이란 동작을 하지 않기 때문에 상속이 불가능하다. 이런 경우 개발자는 울며 겨자 먹기로 move()를 복붙 할 수밖에 없다. 

trait은 어떨까? 만약 trait을 위처럼 animal trait 하나로 만들고, 그 안에 move(), eat()의 메소드를 만들어 둔다면, 위와 같은 문제가 발생할 것이다. 하지만 trait 구현은 일반적으로 그렇지 않다. trait은 '공유 행동'을 보통 표현하게 되기 때문에, move trait과 eat trait을 각각 정의한다. 

정리하자면, 개념상 interface는 카테고리(is-a)와 같고, trait은 tag(#move #eat)와 같다고 할 수 있다.

(이 부분 보충 필요...)

참고

https://www.reddit.com/r/rust/comments/cn20vu/traits_vs_interfaces/

https://doc.rust-lang.org/book/ch10-02-traits.html