Bluetooth는 주변에서 자주 접하는 무선 통신 방법 중 스마트폰, 마우스, 이어폰 등 여러 방면에서 사용 되는 근거리 무선 통신방법의 하나로, Bluetooth v4.0기준 2가지 기술로 구분하고 한다.

– Bluetooth Classic

– Bluetooth Smart (BLE)

– Bluetooth Smart Ready(Classic and Smart)

출처 : http://www.Bluetooth.com

Bluetooth Classic은 데이터 스트리밍, 대용량의 데이터 전송 서비스를 지원하며 최대 데이터 전송률과 전력소모가 높다는 특징을 갖고 있어 적은 용량의 배터리 사용 및 작은 데이터 전송을 사용 하는 분야에서 약점을 갖고 있다. 이를 보안하기 위해 등장한 기술이 Bluetooth Smart 또는 BLE라 불리는 경량화된 Bluetooth v4.0 기술이다.

출처 : http://verticalplatform.kr/archives/2010

Beacon과 BLE(Bluetooth Low Energy)

Apple과 Paypal이 최근 공개한 BLE 방식의 Beacon 방식은 아니지만 두 사업자들 보다 먼저 Beacon을 이용해 솔루션을 구축한 사업자가 있다. Local Commerce의 구세주라 불리우는 Shopkick이다. Shopkick은 저주파 Sound Beacon을 통해 자동체크인 기능을 중심으로 모바일 리워드 서비스를 제공며 약 3년간  500만 명의 가입자를 확보하는 등 성공가도를 달리고 있다. 이미 Beacon을 이용해 성공한 사업자가 있었음에도 불구하고 최근 Beacon이 주목을 받는 것일까? 그 첫번째 이유로 BLE 기술을 꼽을 수 있다. 

Bluetooth 기술은 1994년 Ericsson의 무선 개발 연구를 기반으로해 1998년 Ericsson, Nokia, Tosiba, IBM, Intel 등이 참여해 조직한 Special Interest Group에 의해 개발되었다. 2010년 6월 30일에 채택된 Blutooth4.0이 가장 최신 버전 이며, Bluetooth4.0은 기존의 버전과 다른 주요 특이점을 가지고 있는데 동전 크기만한 전지만으로 1년 이상 Device를 사용할 수 있을 정도로 저전력의 장점을 가지고 있다. 또한 2011년 말에 Bluetooth Smart와 센서를 위한 Bluetooth Smart가 BLE의 새로운 로고로 선보였다. 또한 이전 Bluetooth 버전의 경우 Slave 기기가 7대 까지만 가능했으나 Bluetooth 4.0부터는 무제한 동기화가 가능하게 되었다.

Shopkick의 Sound Beacon과 비교해 기기의 소형화, 저전력화, 그리고 벽과 같은 물리적인 환경 요인의 영향이 적은 Bluetooth 의 장점들으로 인해 Apple과 Paypal은 BLE를 선택한 것으로 판단된다. 이미 이러한 장점들로 인해 다양한 IoT 제품들이 대부분 Bluetooth를 적용하고 있다.

Beacon과 NFC (Payment & 위치측위)

Google은  NFC 기반 Wallet 서비스를 통해 Local Commerce Redemption Loop를 닫고자 했으나 이해관계자 간의 불화와 동글 보급에 대한 문제 등으로 인해 현재까지 결제 또는 전자태그를 이용한 정보를 읽는 수준의 서비스만이 제공되고 있다. 최근 Google이 Cloud 기반의 Google Wallet 서비스를 지원함에 따라 NFC의 종말을 암시하는 것이 아니냐는 목소리가 힘을 얻고 있다. 이런 상황속에 Paypal과 Beacon을 이용한 결제 서비스를 공개 함에 따라 모든 이들이 BLE Beacon에 주목하게 만들었다. Apple 역시 결제와 연계한 실내 위치 측위 기반의 플랫폼이 iBeacons를 내놓음에 따라 Beacon은 더욱 주목을 받을 수 밖게 없는 분위기다.

BLE Beacon은 NFC와 비교해 전송거리가 10~50 미터 까지 넓기 때문에 위치측위 기능을 통한 마케팅 플랫폼과 결제 서비스를 통합해 제공할 수 있는 우위를 가지고 있다. 뿐만 아니라 BLE Beacon은 NFC 보다 이해관계자가 적어 Local Commerce Redemption Loop를 닫을 수 있는 Key Man이 되지 않을 까하는 기대를 모으고 있다. (Redemption Loop에 대한 자세한 내용이 알고 싶으면 9월 28일에 올라온  "커머스 플랫폼의 성공, 'Redemption Loop'를 닫는데 달렸다."  참조)

개방성으로 인한 잠재력

Beacon으로서 Apple의 iBeacons이 Shopkick과 비교해 더 주목을 받는 이유는 3rd Party 개발자들(ex. Estimote, Roximity 등)의 참여로 다양한 풍부한 애플리케이션이 개발되고 이를 다시 스마트폰 이용자가 이용하게 되는 생태계를 구축했다는 점이다. 또한 Passbook 역시 iBeacons 생태계와 통합되어 Passbook에 저장된 티켓 또는 쿠폰 등이 iBeacons을 통해 좀더 정교한 위치 기반으로 Alert 기능을 제공할 것으로 보인다. Shopkick의 솔루션이 3rd Party 개발자를 포함해 생태계를 구축한다면 현재 단계에서 1단계 Quantum Jump를 할 수 있는 기회를 마련 할 수도 있지 않을까라는 개인적인 생각을 해본다.

현재 세상에서는 여러 무선 통신 규격이 존재합니다.
그 중 WiFi 의 동향에 대해 간략하게 소개합니다. ^^

우리 생활에 통신 기술이 발전해온 과거를 조금 되짚어 보겠습니다.. (제 인생 기준 ^^)

1990년대는 모뎀을 이용한 PC통신이 한창 유행이었습니다. (하이텔, 나우누리, 천리안 등)

2000년대 들어서면서 광케이블을 이용한 초고속 유선 인터넷을 통해 인터넷이 보급화 되기 시작했습니다.

2005년 쯤일까요 데스크탑이나 노트북에 사용되는 블루투스를 이용한 무선 마우스, 무선 키보드가 보이기 시작했고,

2007년에는 아이폰이 등장하면서 WiFi을 이용한 무선인터넷, 블루투스를 이용한 오디오 송수신이 활성화 되기 시작합니다.

2009년에 아이폰이 국내 통신사를 통해 정식으로 보급되면서 WiFi와 블루투스 라는 기술은 빠르게 확산되고 인식됩니다.
             이때, 스마트폰이라는 용어가 나돌기 시작합니다.

2010년 이후, 무선통신을 이용한 제품들이 쏟아져 나오기 시작합니다. 
          무선 스피커, 무선 헤드폰, TV 무선연결, 자동차에 접목, 가전제품 접목을 통한 홈네트워크 등
          기존에 있던 제품들에 이러한 무선통신이 탑재됩니다.

그리고 언제부턴가 유비쿼터스라는 용어가 나돌더니, 요즘은 IoT 라는 용어가 나돌기 시작합니다. ㅋㅋ
크게는 둘다 비슷한 뜻으로 어디서든 통신이 이루어지는 세상이 그려지네요.

최근 센서 관련 연구개발에 발을 들여놓게 되어서 무선통신에 다시 관심이 쏟기 시작하는 요즘입니다.

서론이 길었네요..ㅋㅋ WiFi 기술이 발전해온 로드맵은 아래와 같습니다.

최근에는 슈퍼와이파이로 불리는 802.11af의 경우,  54~790MHz사이의 VHF와 UHF에서 TV 화이트 스페이스(TVWS)에서 무선인터넷을 가능하게 하는 무선표준기술입니다.  기존무선보다 도달거리가 3배이상 높고, 투과율은 9배, 커버리지 면적은 16배에 달하는 것으로 알려져있습니다.

                                     [TTA 저널 제공]

                                    [TTA 저널 제공] 

아래는 최근 WiFi 이용 동향에 관한 기사입니다.

http://www.etnews.com/20161117000312

무선 인터넷 구축비 10분의 1로 줄인다···TVWS 내달부터 이용 가능

무선 인터넷 구축 비용을 10분의 1 이하로 줄일 수 있게 된다. 산간 오지 등 취약 지구뿐만 아니라 경제성을 이유로 설치가 어려운 지역에도 무선 ...

www.etnews.com

http://www.datanet.co.kr/news/articleView.html?idxno=107039

802.11ac 웨이브 2 확산 본격화…IoT용 무선 표준 주목 - 데이터넷

모바일 및 무선 기술의 지속적인 진화는 모바일 퍼스트 시대를 앞당기고 있다. 이에 개인의 일상을 넘어 엔터프라이즈 모빌리티, 스마트워크 구현...

www.datanet.co.kr

[출처] 슈퍼와이파이(Super WiFi) 802.11af 란?|작성자 언제리

출처 : http://unjerry.blog.me/220991647323

(출처 : 소프트웨어 센터 웹진 자료)

IoT 사례 연구 - 빅데이터와 연계 

IoT(Internet of Things)의 시대에는 빅데이터를 빼놓고 말할 수 없을 만큼 중요한 요소이다. 엄청난 양(Volume)의 다양한(Variety) 데이터가 엄청난 속도(Velocity)로 쏟아지기 때문이다. 반대로, 빅데이터는 대량의 데이터가 입력되지 않으면 가치를 찾기 어렵기 때문에 빅데이터와 IoT는 뗄 수 없는 관계일 수 밖에 없다. 이번 회에서는 IoT와 빅데이터를 활용하기 위해 사용되는 구성에 대해 알아보기로 한다. 상호 보완적 개념인 빅데이터와 IoT를 연결한 컴퓨팅 구성을 이해하는데 도움이 되기를 기대한다. 

사례 연구 전 확인 사항 

IoT와 빅데이터 

IoT는 사물이 다양한 센서를 통해 수집한 데이터를 네트워크를 통해 전달하는 것이 일반적인 역할이라고 할 수 있다(그림1). IoT에서 수집하는 데이터는 실시간 데이터가 대부분이기 때문에 사물이 24시간 동안 인터넷에 접속되어 있으면서 쉬지 않고 데이터를 수집한다. 이러한 일을 위해 과거에는 많은 비용과 기술이 필요했지만 현재는 디바이스가 점점 소형화 되면서 비용도 함께 내려가는 추세다. 따라서, 지금은 거의 모든 산업에서 IoT를 이용해 빅데이터를 수집하고 있다. 

 <그림1> IoT의 데이터 수집과 전달 

 출처: http://www.tkt.cs.tut.fi/research/waps/ 

IoT와 빅데이터, 그리고 클라우드 

IoT, 클라우드(Cloud), 빅데이터를 ‘제3의 IT혁명’이라고 불리고 있다. IoT 센서를 통해 빅데이터를 수집하고, 수집된 빅데이터를 정제하고 분석, 이를 다시 서비스하기까지 클라우드 환경이 구축되어 있어야 가능하기 때문이다. 실제 세상의 정보를 센서를 통해 수집하고, 이를 디지털화하여 정제, 분석한 후 디지털 세상에 저장하고, 분석된 결과를 실제 세상에 다시 제공한다. 실제 세상과 디지털 세상을 이어주는 역할을 클라우드가 하게 된다(그림2). 

<그림2> IoT, Cloud, Big data의 연결 

출처: SK Telecom - The ERA of Smart things 

지금까지도 수집된 데이터는 대부분 실시간으로 저장하는 경우가 많았다. 하지만, IoT가 쏟아내는 빅데이터의 양은 시간이 갈수록 기하급수적으로 늘어나기 때문에 데이터센터를 구축해도 감당하기 힘든 경우도 발생할 수 있다. 따라서, 센서에서 수집되는 데이터를 효율적으로 수집하고 분석하는 것도 중요하지만 효율적인 데이터 전송, 저장 방법도 중요한 요소로 남아있는 상태다(그림3). 

<그림3> IoT, Cloud, Big data의 연결의 예 

출처: Cisco blog - IoT Platform Architecture 

IoT를 통한 실시간 빅데이터 분석의 필요성 증대 

IoT에서 수집하는 빅데이터의 증가로 인해 수집된 빅데이터를 분석하기 위해 저장할 수 있는 시간과 공간이 점차 줄어들고 있다. 이로 인해, 필요성이 증가하고 있는 것이 실시간 빅데이터 분석이다. 일반적인 데이터 분석은 데이터의 생성 시점과 분석 시점을 크게 고민할 필요가 없지만, 실시간 분석은 데이터가 생성되는 시점에 분석을 해야 하기 때문에 다양한 방법들이 연구되고 있다. 센서나 소셜 미디어에서 생성되는 시계열 데이터나 로그 데이터가 주 대상이며, 머신 데이터는 빅데이터 중에서도 증가세가 가장 빠른 영역이다. IoT 활용에서 실시간 빅데이터 분석의 중요성이 강조되는 이유는 IoT에서 수집하는 데이터가 워낙 방대하기 때문에 계속 쌓아놓고 데이터를 볼 경우 원하는 IoT 활용이 어렵기 때문이다. 그림4와 같은 방법으로 IoT를 활용한 실시간 데이터 분석이 가능하다. 

<그림4> 실시간 데이터 분석 방법 

출처: http://www.openwith.net/?page_id=976 

<참고사이트> 

사례 연구 

시스코(Cisco) - 포그 컴퓨팅(Fog Computing) 

IoT의 확산과 빅데이터의 양과 실시간 처리의 필요성이 증가하고 센서 디바이스의 한계로 인해 클라우드 컴퓨팅의 영역보다 더 확대된 역할이 필요하게 되었다. 클라우드 컴퓨팅을 실제 네트워크에 보다 근접한 경계 영역까지 확장하는 새로운 아키텍처가 제시되었는데 이 것이 포그 컴퓨팅이다(그림5). 

<그림5> 포그 컴퓨팅의 구성 

출처: Cisco 

포그 컴퓨팅은 센서나 디바이스에서 생성된 데이터를 실시간으로 처리할 수 있는 노드를 기지국처럼 두고 컴퓨팅 파워가 필요한 데이터만 클라우드로 넘겨서 처리하는 방식이다. 노드에는 컴퓨팅에 필요한 메모리나 저장 기능을 가지고 있어 즉각적인 데이터 분석이 가능하도록 되어 있다. 스마트폰과 같은 디바이스에서 생성된 데이터를 근거리 통신망을 이용해 포그 노드에 연결하여 분석하고, 그 이상의 컴퓨팅 파워가 필요한 작업은 클라우드로 보내 처리하게 한다. 이러한 방식은 간단한 데이터 분석은 포그 노드에서 해결하기 때문에 데이터 분석에 필요한 비용과 시간을 절약할 수 있고, 대부분 데이터 분석이 완료된 데이터가 네트워크를 통해 저장되기 때문에 빅데이터 저장공간도 줄일 수 있는 장점이 있다. 아키텍처를 보면 컴퓨터, 네트워크, 저장장치가 있고, 사용자 위치 파악해 주는 엔진과 그 위에서 애플리케이션이 구동된다. 이러한 아키텍처가 라우터나 셋톱박스, AP 등에 탑재될 수 있다. 즉, 전통적인 컴퓨팅 모델과 비교하면, 물리적인 디바이스와 인터넷 사이에 분산 플랫폼을 가지고 있는 것이다.(그림6). 

<그림6> 전통적 컴퓨팅 모델과 포그 컴퓨팅 모델의 비교 

출처: Cisco 

파스트림(ParStream) 

고성능 압축 비트맵 인덱스(HPCI; High Performance Compressed Index) 기술을 특허 등록하여 사용하는 파스트림은 수십억 건의 데이터도 1초 이내 분석 결과를 도출할 수 있다고 알려져 있다. IoT를 통한 빅데이터 분석에 강점이 있는 이유가 여기에 있다. 파스트림의 가장 큰 특징은 하둡 기반이 아닌 관계형 데이터베이스 기술을 적용한다는 점이다. 이 것은 사용자가 기존에 사용하던 SQL과 관련 기술을 그대로 사용할 수 있다는 장점이 있다. HPCI 기술은 압축 해제 없이 바로 쿼리가 가능하도록 한 것(그림7)으로 압축 해제에 필요한 CPU나 메모리의 성능 저하나 처리 시간이 필요 없다는 장점을 가지고 있다. 

<그림7> HPCI 개념 

출처: 파스트림 

데이터스트림즈의 TeraStream Bass 

데이터스트림즈에서는 IoT를 통한 빅데이터 실시간 분석을 위한 메모리 기반 플랫폼을 제시하고 있다(그림8). 전력장비, 보안장비, 로그데이터 등을 실시간으로 수집하여 실시간 인덱싱 후 데이터를 메모리에 분산 저장하는 방식이다. 오래된 데이터나 사용자 설정을 벗어나는 데이터는 Hadoop의 HDFS에 분산 저장 처리하여 실시간 처리 요건과 Batch처리 요건을 동시에 만족할 수 있는 Hybrid 분석 기능을 제공하는 것이 특징이다. 수집된 데이터를 메모리와 디스크에 분산 저장하기 때문에 사용 빈도가 높은 것은 메모리에 위치할 수 있어 분석과 검색 속도가 빠르다는 장점이 있다. 메타데이터를 활용해 메모리와 하둡에 저장하는 데이터를 구분하는 것도 좀더 체계적인 기준으로 데이터를 분산 배치할 수 있다. 

<그림8> 데이터스트림즈의 IoT를 통한 실시간 데이터 처리 

출처: 데이터스트림즈 

기대 효과와 결론 

IoT와 빅데이터 간의 연계는 소프트웨어적인 요소보다는 아키텍처적 요소가 많이 반영되어 있지만 센서나 디바이스의 네트워크 연계, 빅데이터의 분석, 저장 등을 위한 입력 데이터의 연계 방법에 대해 알고 있어야 효율적으로 전체 아키텍처를 구성할 수 있다. IoT를 통한 빅데이터 활용의 최근 트렌드는 실시간 분석이기 때문에 IoT의 센서나 디바이스의 데이터 수집 부담과 데이터를 분석하고 저장하는 부담을 줄이기 위한 노력이 계속되고 있다.

출처 : http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000045319&currPage=1&searchPrefaceId=&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=IoT+%EC%82%AC%EB%A1%80+%EC%97%B0%EA%B5%AC 

(출처 : 소프트웨어 센터 웹진 자료)

IoT 사례 연구 - 개발 기법 

IoT(Internet of Things) 소프트웨어는 기존 ICT(Information & Communication Technology) 소프트웨어와는 다소 상이한 부분이 있다. IoT 기반 소프트웨어의 경우 IoT 디바이스를 중심으로 개발되어야 하기 때문에 소프트웨어 개발부터 운영까지 확인해야 할 사항들이 존재한다. 이번 회에서는 IoT을 위한 소프트웨어의 구성과 개발에 관해 알아보기로 한다. IoT 기술 적용을 위한 소프트웨어의 요소를 이해하는데 도움이 되기를 기대한다. 

사례 연구 전 확인 사항 

IoT는 사물을 이용한 방식이기 때문에 디바이스와 네트워크에 대한 제어를 소프트웨어에 포함시켜야 하는 경우가 많다. 기존에는 각 산업이나 서비스에서 필요한 정보만을 수집하다 보니 소프트웨어의 규모도 그리 크지 않았지만, 최근에는 엄청난 양의 정보가 수집되어 소프트웨어의 규모도 커지고 그에 필요한 아키텍처도 다양해지는 추세다. 이렇게, 정보를 한 곳으로 모았다가 다시 필요한 곳으로 정보를 제공하는 중앙 집중 식 클라우드 형태가 현재 많이 사용되는 모델이고, 이후 분산 클라우드 형태의 IoT가 많이 연구되어 발표되고 있는 추세다. 

<참고사이트>

이처럼, IoT의 모델이 다양하게 존재하지만, 소프트웨어 입장에서 근본적인 IoT의 모델은 다양한 사물에서 데이터를 수집하는 형태다(그림1). 기존에는 단독 사물에서 데이터를 수집하는 형태였지만, 여러 사물에서 중앙집중식으로 변화가 일어나면서 소프트웨어는 더 많은 디바이스와 연결하고 더 많은 데이터를 가져오는 것으로 변화됐다. 

<그림1> IoT 모델의 변화 

출처: 전자부품연구원  

그림1에서 보는 것처럼, 소프트웨어 관점에서는 표준화된 플랫폼을 구축하여 다양한 디바이스와 네트워크의 제어가 가능하게 된다. 아래는 이렇게 표준화된 플랫폼 기반에서 다양한 IoT 서비스 위한 소프트웨어 개발에 필요한 능력이다. 

IoT 디바이스를 제어하기 위한 시스템 소프트웨어 개발 능력 

IoT를 위한 디바이스들은 모바일폰과 같은 스마트 디바이스와는 다르게 센서와 같은 하드웨어 측면의 부가적인 기능을 가진 디바이스가 많다. 이러한 기능을 원활히 동작하게 하고 다양한 하드웨어를 추가하기 위해서는 유연성과 확장성이 필요하다. 이를 위해, 펌웨어보다는 임베디드 적용이 필요하고 임베디드 기반의 소프트웨어 개발 능력이 요구된다. 여기서, 기존의 임베디드는 하드웨어 중심의 기능은 단순하고 독립적으로 구성되었지만 IoT가 적용되면서 최근에는 소프트웨어를 중심으로 구성되어 많은 기능을 제어할 수 있고 확장이 용이하게 변화되었다(그림2). 하드웨어의 비중이 줄어들고 유연한 확장이 용이한 소프트웨어 중심의 임베디드 시스템 설계가 이루어지고 있기 때문이다.

<그림2> IoT 모델 변화에 따른 임베디드 시스템의 변화 

출처: RENESAS 

IoT 네트워크와 인터페이스를 위한 소프트웨어 개발 능력 

IoT의 발전과 함께 빠질 수 없는 요소가 IoT 게이트웨이(Gateway)다. IoT 게이트웨이는 각 디바이스에서 수집되는 데이터를 모아 전송하기 때문에 IoT 게이트웨이가 있으면 디바이스가 꼭 인터넷에 접근할 필요가 없어 네트워크 대역폭의 부담을 낮출 수 있다. 또한, 불필요한 데이터는 거르고 필요한 데이터만 전송하도록 한다면 데이터의 신뢰도를 높이고 네트워크의 트래픽을 낮출 수 있다. 또, 통신 네트워크와 인터페이스의 유연한 확장을 위해서도 소프트웨어를 통한 제어가 필요하다. 

<그림3> IoT 게이트웨이를 적용한 IoT 구성 

출처: Intel 

IoT에서 수집된 빅데이터를 지식화 하기 위한 소프트웨어 개발 능력

IoT는 엄밀히 IoT 자체적인 서비스는 거의 없다. 대부분 IoT에서 수집된 정보를 활용하는 서비스이다. IoT 소프트웨어에 빅데이터 관련 개발 능력이 필요한 이유다. 사물에서 데이터를 수집하고 네트워크를 통해 전달한 후 빅데이터 활용 프로세스에 맞춰 서비스를 제공한다(그림4). 

<그림4> IoT를 통한 빅데이터 수집 및 활용 

출처: 공개소프트웨어포털  

<참고링크>

IoT 플랫폼은 위 세 가지를 적용하여 구성할 수 있다(그림5). 특정 디바이스만이 아닌 일반적인 디바이스는 모두 제어할 수 있고 인터페이스를 통해 데이터를 주고 받을 수 있으며, 빅데이터 수집, 분석, 정보화 등을 통해 다양한 서비스를 제공하게 된다. 이러한 일들은 소프트웨어를 통해 유연하게 확장할 수 있고, 서비스 특성에 따라 소프트웨어를 설계하면 된다. 

<그림5> IoT 플랫폼의 예 

출처: 사물인터넷 - 개념, 구현기술 그리고 비즈니스 

IoT 플랫폼을 사용하게 되면 전통적인 소프트웨어 개발보다 현저히 줄어든 개발 기간을 확인할 수 있다(그림6). 왜냐하면, 센서와 디바이스, 네트워크와 인터페이스의 제어 방법이 플랫폼에서 제시될 수 있고, 빅데이터 수집과 분석 후 서비스를 제공하는 방법까지 플랫폼에서 정의될 수 있기 때문이다. 

<그림7> 전통적인 개발과 플랫폼을 사용한 개발의 비교 

출처: RENESAS 

그림7을 살펴보면, 위 쪽의 전통적인 개발에서는 드라이버, 미들웨어 설계까지 포함되어 있지만 아래는 그 부분이 모두 플랫폼에 포함되어 있기 때문에 별도의 설계나 개발이 필요하지 않다. 그리고, 기존 개발에서는 요구사항에 따라 기능에 필요한 하드웨어를 선택하고 주변 하드웨어를 설계하지만, 플랫폼 기반에서는 사용자가 사용하는 기능에 따라 플랫폼에서 사용자가 필요한 부분을 정의하고 적당한 소프트웨어를 개발하면 된다. 

사례 연구 

AWS 플랫폼 

AWS IoT 플랫폼은 디바이스에 SDK(Software Development Kit)을 제공하고, 게이트웨이를 통해 애플리케이션과 디바이스 간의 통신을 제공해주고 있다(그림8). 플랫폼 밖인 디바이스에서 정보를 쉽게 전달 받고 플랫폼의 인증과 다양한 개발 라이브러리 등도 활용할 수 있도록 SDK를 제공하고 있다. 

<그림8> AWS IoT 플랫폼 

출처: Amazon 

규칙 엔진(Rule Engine)을 사용하면 인프라를 관리할 필요 없이 디바이스에서 수집된 데이터를 처리, 분석할 수 있고, 비즈니스 규칙에 따라 다른 디바이스나 클라우드 서비스로 이를 변환하거나 전송할 수 있다. 그림에서 보는 것처럼 IoT 서비스에 따라 달라질 수 있는 디바이스나 애플리케이션을 제외한 부분을 플랫폼으로 구성하면서 아키텍처의 강건성이 매우 높아질 수 있고 개발 기간이나 복잡도를 낮출 수 있다. 

<참고사이트>

LG CNS의 IoT 플랫폼 

LG에서는 나날이 발전하고 있는 IoT 시장을 위해 6가지 기술을 정의하여 발전 전략을 수립했다. 아래를 살펴보면, 디바이스 관련 기술(⑤), 네트워크와 인터페이스 관련 기술(①②), 빅데이터 관련 기술(③)과 이를 통합 지원하는 기술(④⑥)로 구분된 것을 확인할 수 있다. 이를 통해, LG가 지향하는 바는 “다양한 디바이스로부터 수집된 대량의 센서 데이터들을 안정적으로 송/수신하고, 클라우드 환경에 저장된 데이터의 처리 및 분석을 통해 지능형 서비스까지 제공하는 플랫폼”이다. 

① Gateway와 Edge Device 관련 기술  

② 대량의 데이터를 안정적으로 전달할 수 있는 통신 기술 

③ 이벤트 처리와 데이터 분석 및 추천을 위한 빅데이터(Big Data) 관련 기술 

④ 위의 언급한 기술들의 Base 제공 및 융합을 지원할 플랫폼과 Enabler 관련 기술 

⑤ 인증/권한을 통한 데이터 보안뿐만 아니라 디바이스와 칩(Chip) 레벨의 보안 기술 

⑥ 사용자와 상호 작용할 수 있는 UI/UX 기술 

LG에서는 디바이스의 쉼 없는 발전과 폭발적으로 증가하는 데이터를 활용한 새로운 비즈니스가 IoT를 통해 나타난다고 하고 있다. 이 때, 특정되지 않은 디바이스나 서비스를 쉽게 받아들이고 표준화된 서비스를 통해 쉽게 IoT 서비스에 접근할 수 있도록 가이드 하고 있다. 그림9는 LG에서 제시하는 IoT 플랫폼인데, 다른 곳에서 제시하는 IoT 플랫폼과 레이아웃이 거의 유사하다.  디바이스→네트워크→서비스 로 이어지는 흐름을 기본으로 하고 있고, 다수의 디바이스와 사용자에 대한 인증, 보안이 추가되어 있기 때문이다. 

<그림9> LG CNS의 IoT 플랫폼 

출처: LG CNS 

기대 효과와 결론 

지금까지 IoT에 대해 아키텍처, 보안, 빅데이터 연계, 개발에 대해 살펴보았다. IoT는 소프트웨어보다는 많은 부분이 하드웨어 중심으로 서비스되어 왔던 것이 사실이다. 하지만, 기하급수적으로 늘어나는 IoT 관련 디바이스와 서비스로 인해 개별적으로 개발이 이루어지는 것은 매우 소모적이고 많은 손실을 가져온다. 체계적이고 표준화된 플랫폼 사용으로 IoT를 활용한 신규 서비스가 더 많이 늘어나기를 기대한다. 

참고자료 

□ https://aws.amazon.com/ko/iot/how-it-works/ 

□ http://www.lgcns.com/ 

출처 : http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000045453&currPage=1&searchPrefaceId=&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=IoT+%EC%82%AC%EB%A1%80+%EC%97%B0%EA%B5%AC

1. Secure Cording
SW개발과정에서 개발자 실수, 논리적 오류 등으로 발생하는 취약점을 최소화하는 보안활동
좁게는 소스코드 구현단계에서의 활동이고,
넓게는 SW 개발생명주기 SDLC 의 각 단계별 요구되는 보안활동이 모두 포함됨

1) 입력데이터의 검증

가) SQL Injection
DB와 연동된 웹 어플리케이션에서 입력되는 데이터에 대해 유효성 검증을 하지 않을 경우,
공격자가 입력폼에 SQL문을 삽입하여 DB로부터 정보를 조회하거나 조작하는 취약점

DB와 연동되는 입력값들에 대해서는
SQL 쿼리문관련 특수문자나 SQL명령어들을 필터링 하도록 코드 구현함으로 해결
(ex) ' or 1=1 #  을 통해 TRUE 값 만들수 있음)

나) XSS (크로스 사이트 스크립트)
웹페이지에서 악의적인 스크립트를 포함시켜 사용자 측에서 실행되도록 유도하여 정보 유출 등의 공격 유발

스크립트 종류
Client Side : JavaScipt는 Client측에 다운로드 되어서 브라우져에서 수행
Server Side : JSP, ASP, C#, PHP 등

- 스크립트의 코드 중에 서버에서 값을 받아오는 부분에 대해서는 해당 값에 대해 문자변환 함수나 메소드를 이용하여
유효성 검증을 함으로 해결
- HTML 태그를 허용하는 게시판에서는 White List 선정후 해당 태그만 허용 (Script 태그 금지 등)

2) 보안기능
인증, 접근제어, 기밀성, 암호화, 권한관리 등을 적절하지 않게 구현시 발생하는 취약점

가) 중요 자원에 대한 잘못된 권한 설정
password와 같은 중요자원에는 관리자에 의해서만 read/write 되도록 설정한다.

나) Cross Site Request Forgery (사이트 간 요청 위조)
사용자 자신의 의지와 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격
사용자의 인증 없이 정보에 접근하거나 위조가 가능해진다.

중요한 정보를 처리하는 웹페이지에서는 사용자 재인증 작업을 거치도록 한다.
(코드상에서 ID/Password를 다시 입력받게해서 기존 session의 ID/Password를 비교하도록 한다.)

3) 시간 및 상태
데드락(dead lock)나 자원에 대한 경쟁조건(race condition)과 같이
프로그램 동작과정에서 프로세스 혹은 쓰레드나 시스템 상태에 대한 정보(자원잠금, 세션정보)에 관련된 취약점을 말한다.

가) 경쟁조건(race condition)
한 자원에 대해 동시에 여러 프로세스 혹은 쓰레드에서 접근을 하려고 하면,
동기화 문제가 발생할 수 있고, 
이를 임계영역에 대한 처리를 해서 해결하지만, 잘못 처리하면 데드락이 발생할 수 있다.

4) 에러처리 
에러를 처리하지 않거나, 불충분하면 에러정보에 중요 시스템 정보가 노출될 수 있는 취약점
ex) java에서 e.printStackTrace()와 같이 디버깅 정보를 보여주는 건 개발 때 사용하는 것으로 상용 땐 위험
    그래서 대신 따로 에러메세지를 출력하도록 하고, 내부적인 예외상황은 로그로 따로 저장하도록 구현해야 함

5) 코드오류
메모리의 부적절한 반환 등 개발자의 코딩오류로 인해 유발되는 취약점
Null이 될 수 있는 레퍼런스는 참조하기 전에 널 값인지 검사하도록 한다.

6) 캡슐화
중요한 데이터를 불충분하게 캡슐화하면, 인가되지 않은 사용자에게 데이터 노출이 가능해지는 취약점
멀티 쓰레드 환경인 java 서블릿 등에서는 정보를 저장하는 멤버변수가 포함되지 않도록 하여
서로 다른 세션에서 데이터를 공유하지 않도록 해야한다.

* 아래는 http://ironmask.net/261 참조

2. Race Condition

3. Buffer Overflow

4. Format String

국내 웹 취약점 진단기준 : 국정원 10대 취약점, KISA 제시 취약점, 행안부 제시 43개 시큐어 코딩 진단기준
--> CVE, CWE, OWASP 에서 나온 문서들을 참고한 것이다.

1. CVE(Common Vulnerabilities and Exposures) : http://cve.mitre.org , CVE-연도-순서 순의 포맷으로 목록화

2. CWE(Common Weakness Enumeration) : http://cwe.mitre.org , 다양한 언어의 소스코드 취약점 목록화

3. OWASP(Open Web Application Security Project) : https://www.owasp.org/index.php/Main_page
--> 웹어플리케이션에 대한 취약점 Top 10 목록화

4. KISA 점검기준 : http://www.kisa.or.kr/public/laws/laws3.jsp

5. 행정안전부 시큐어코딩 항목 : http://www.mospa.go.kr/

OWASP 2013에 대표적 3가지

1) SQL Injection
   - 유형별
      ㄱ) Error Base SQL Injection : SQL시스템에서  error 리턴시, 그 정보를 이용하여 취약점 찾음
      ㄴ) Blind SQL Injection : 쿼리의 참과 거짓을 통해 데이터 추출
   - 공격방식별
      ㄱ) Form SQL Injection : 입력폼에 쿼리문 Injection
      ㄴ) Union SQL Injection : union select 쿼리문 이용하여 한 쿼리의 결과를 다른 쿼리의 결과에 접합
      ㄷ) Stored Procedure SQL Injection : 일련의 쿼리를 함수처럼 실행
      ㄹ) Mass SQL Injection : 한 번의 공격으로 대량의 DB값이 변조 (악성스크립트 이용)
   - 대안
     ㄱ) DB와 연동되는 스크립트의 모든 패러미터 유효성 검증, SQL 특수문자 필터링
     ㄴ) 입력 문자열 길이 제한

2) XSS (cross site script)
   - 유형별
      ㄱ) Stored XSS - 웹서버내에 DB에 악성스크립트가 저장 - 게시판, 방명록 등에서..
      ㄴ) Reflected XSS - 악성스크립트가 공격사이트가 아닌 다른 사이트에 있는 경우
   - 대안
      ㄱ) 사용자 입력값은 반드시 서버단에서 검증 (특수문자는 변환함수로 치환)
      ㄴ) 게시판에서 HTML 태그 허용시, White List 선정후, 해당 태그만 허용 (Script 태그는 금지 등)

3) CSRF 공격 (cross site request Forgery)
웹어플에서 정상적 경로 통한 요청과 비정상 결로 통한 요청을 서버가 구분하지 못할 경우에,
공격자가 스크립트 구문 이용하여, 정상 사용자로 하여금 조작된 요청을 전송하도록 하여
설정 및 정보 변경시키는 경우
   - 대안
      ㄱ) Get 보다는 POST 방식 사용 (Get은 url에 sql문이 노출?)
      ㄴ) 중요기능에는 세션검증과 재인증을 유도한다.

새롭게 TOP 10 에 추가된 3개 항목은 다음과 같습니다.

1. XML External Entities (XXE) 

XXE 라고 부르는 'XML 외부 엔터티' 취약점은 XML 문서의 DTD 구조 정의 시 Entity 항목을 설정할 수 있을 때 발생하는 취약점 입니다.

XML 문서는 마치 변수를 선언한 것 처럼 Entity를 선언하여 사용 할 수 있는데, Entity 선언 시 외부 리소스로 선언이 가능합니다.

아래 코드와 같이 외부 파일, 가령 운영체제의 계정 정보가 기록된 passwd 파일을 외부 엔터터로 선언하고 XML 문서 내에서 '&엔터티명'을 호출하면 해당 파일 내용을 핸들링 할 수 있습니다.

<?xml version="1.0" encoding="ISO-8859-1"?>

 <!DOCTYPE foo [<!ELEMENT foo ANY >

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

 <foo>&xxe;</foo>

참고로 일반적으로 마크업 문서에서 <, > 대신 사용하는 &lt, &gt 는 기본적으로 선언된 Entity 입니다.

2. Insecure Deserialization

Javascript 를 비롯하여 여러가지 개발 언어에서 여러가지 이유로 데이터 혹은 객체를 전송할 때 직렬화(Serialization)을 수행하게 됩니다. 가령 특수 문자나 공백등의 구분자가 포함되어 있다던가, 바이너리 데이터를 전송할 필요가 있다던가 URL 호출로 직접 데이터를 전송 할 경우 일반적으로 사용합니다.

이렇게 serialization 된 정보 전송 시 별도의 무결성 검증이나 암호화를 수행하지 않을 경우 프로그램에 영향을 줄 수 있는 악의적인 정보를 전송할 경우 원래 데이터로 복원하는 Deserializtion 시 문제를 발생시킬 수 있습니다.

3. Insufficient Logging & Monitoring

악의적인 공격 징후에 대한 로그를 남기지 않거나 로그를 기록하더라도 모니터링을 수행하지 않으면 지속적인 공격의 대상이 될 수 있습니다.

공격의 징후 (가령 대량의 포트 스캐닝, Brute force 공격 등)에 대한 로그 기록과 지속적인 모니터링을 통해 공격 징후를 파악하고 사전에 공격을 차단할 수 있도록 방비해야 합니다.

[출처] OWASP TOP 10 2017 릴리즈|작성자 강군

2013 버전과 비교하면 몇가지 변경사항들이 좀 눈에 띄입니다. 특히 2013 버전에 있던 CSRF(크로스 사이트 요청변조)가 이번 버전에서 빠졌는데, OWASP 그룹에 따르면 CSRF는 13위에 랭크되어 이번 TOP 10 에서는 제외되었다고 합니다.

아래는 OWASP Top 10 -2017 관련 내용입니다.

출처 : https://blog.naver.com/PostView.nhn?blogId=crehacktive3&logNo=221162402841&proxyReferer=https%3A%2F%2Fwww.google.com%2F

드디어 OWASP Top 10 - 2017 최종 버전이 공개되었습니다. 지난번 OWASP Top 2017 RC1 항목에 관해 포스팅을 하였는데 그때와는 다소 항목이 변경된 것을 아래 그림을 통해 알 수 있습니다. 이전 OWASP Top 10 - 2013 버전 보다 훨씬 더 직관적으로 항목이 변경되었으며, 최신 트랜드를 반영한 것을 알 수 있습니다.

OWASP Top 10 - 2013, OWASP Top 10 - 2017 항목 비교

아래는 본문 내용에서 발췌한 내용입니다.

데이터가 제공한 새로운 문제: 

- A4:2017-XML 외부 개체(XXE)는 주로 소스 코드 분석 보안 테스팅 도구(SAST) 데이터 집합에서 지원되는 새로운 범주입니다.

커뮤니티가 제공한 새로운 문제: 

우리는 커뮤니티가 지켜보고 있는 두 가지 취약점에 대한 통찰력을 제공할 것을 요청했습니다. 500개 이상의 개별 제출 및 민감한 

노출, XXE와 같은 이미 제시된 데이터를 제거한 후 다음과 같은 두 가지 새로운 문제가 있었습니다: 

- A8:2017-안전하지 않은 역직렬화는 영향을 받는 플랫폼에서 원격 코드 실행 또는 중요한 개체 조작을 허용합니다. 

- A10:2017-불충분한 로깅과 모니터링은 악의적인 활동 및 침입 탐지, 사고 대응 및 디지털 포렌식을 방해하거나 크게 지연시킬 수 

있는 결함이 있습니다. 

병합했거나 삭제됐지만, 잊지 말아야 하는 사항: 

- A4-안전하지 않은 직접 객체 참조와 A7-기능 수준의 접근 통제 누락은 A5:2017-취약한 접근 통제 항목으로 병합되었습니다. 

- A8-크로스-사이트 요청 변조 (CSRF)은 CSRF 방어를 포함한 많은 프레임워크에 있기 때문에 5%의 애플리케이션에서만 

발견되었습니다. 

- A10-검증되지 않은 리다이렉트 및 포워드는 약 8%의 애플리케이션에서 발견되었지만 XXE에 밀려났습니다

OWASP Top 10 - 2017(한글버전 PDF)

https://www.owasp.org/images/b/bd/OWASP_Top_10-2017-ko.pdf

OWASP Top 10 - 2017(영문버전 PDF)

https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

1. ARP Spoofing
: 논리주소(IP) -> 물리주소(MAC) 로 변환해주는 프로토콜인 ARP를 이용하여,
  ARP Request를 계속해서 보냄으로써 공격대상 통신장비에 ARP Cache Table에 저장되어 있는
  임의의 IP, MAC 주소를 자신의 주소로 변경시켜서, 통신데이터를 Sniffing 하는 공격
--> arp -s ip주소 명령어로 정적주소로 타입을 등록함으로 ARP Cache Table 변경을 막는 방법이 있다.

2. ping, traceroute
: ping은 TCP/IP방식의 3계층인 IP프로토콜의 신뢰할 수 없는 전송을 관리해주는 ICMP의 메세지 중
  echo request(type 8), echo reply(type 0)을 이용하여, 네트워크 속도 및 손실률을 검사하는 유틸이다.

: traceroute는 여러 중계 라우터 각 구간에 대한 네트워크 상태를 관리하는 유틸
  ICMP 메세지 중 Time Exceeded(Type 11)와 Destination Unreachable(Type 3)을 이용하고,
  IP헤더에 포함된 TTL(Time To Live) 을 이용한다.

3. ICMP Redirect 공격
:   ICMP Redirect는 라우터만이 보낼수 있는데, 이를 공격자가 자신이 라우터 인것처럼 보이기 위해 IP헤더에
    source ip를 라우터의 주소로 위조하여 보내고, 라우팅 테이블을 변조시킨다.
   보안상의 이유로 일반적으로 OS에서 ICMP Redirect 옵션을 기본적으로 해제한다.
   리눅스에서는 sysctl -w 명령어 이용

4. ifconfig eth1 promisc (2계층 스위치 관련): 자신에게 온 패킷이 아니어도 다 받는다. Sniffing 목적 

5. DNS Spoofing 공격 (DNS는 도메인명 -> IP주소 로 변경해주는 것)
: 희생자가 DNS 쿼리를 수행하면 공격자가 이를 스니핑하고 있다가 희생자 호스트에 위조된 웹사이트로 접속하는
  DNS응답을 보내 위조된 주소로 접속하게 만드는 공격이다. DNS는 UDP를 이용하므로 비연결이라는 특성의 취약점을
  이용하여, 트랜잭션ID만 일치하면 먼저 들어온 응답을 신뢰하는 특성 이용한 것
  --> 중요한 사이트는 hosts 파일에 등록하여, DNS응답보다 우선순위가 높은 hosts파일을 참조하도록 하여 해결 

** 참조 우선순위 : hosts파일 -> 호스트의 dns cache -> resolv.conf파일에 등록된 dns서버정보에 질의

6. DNS Cache Poisoning
: DNS서버의 캐시 메모리에 위조된 데이터를 저장하여 호스트는 이 위조된 정보를 사용하도록 유도는 방식의 파밍 공격
  해당서버에 접근하는 호스트들이 위조된 정보를 응답받으므로 피해가 크다.
  DNS서버가 질의를 받을때, 자신의 Cache에 해당 정보가 없으면 Root DNS서버부터 순환질의를 하는데,
  이틈에 해당 DNS서버에 공격자가 Cache에 정보를 먼저 업데이트 시켜버린다.
  --> DNSSEC 기술을 이용 (기존 DNS에서 공개키 암호화  기능을 추가 부여)
  --> named.conf 파일을 수정하여 재귀적 질의 제한, zone transfer파일 제한

7. DNS Lookup 하는 명령어 (도메인 -> IP주소)
   1) nslookup
   2) dig : nslookup을 대체하기 위함, 리눅스 및 유닉스 계열에는 기본 설치

8. DHCP : 동적으로 클라이언트의 네트워크 주소 (IP)를 설정하기 위한 프로토콜
   * DHCP Starvation 공격 : 할당가능한 IP를 모두 소진하게 만들어  IP할당이 불가능하게 하는 공격
     --> 서로다른 MAC주소로 대량으로 보냄 -> 이에대한 offer 오면 -> request메세지까지 보내고 실제로는 할당안함

9. DDOS : C&C서버(Command & Control)를 이용하여, Bot/좀비PC 들을 컨트롤하여, 타겟을 공격한다.
   ex1) DNS Query Flooding : UDP프로토콜 기반의 서비스를 제공하는 DNS에 대해 DNS쿼리 데이터를 다량으로 서버에
          전송하여 DNS의 정상적인 서비스를 방해
   ex2) TCP SYN Flooding : 공격자는 다량의 SYN패킷을 서버로 전달하여 서버가 새로운 클라이언트의 연결요청을
          처리하지 못함 (syn+ack 받고, ack를 보내지 않아서 처리되지 않은 정보를 계속 쌓이게 만든다.)
   ex3) HTTP Get Flooding : 공격자는 동일한 URL을 반복 요청하여 웹서버가 URL에 대해 데이터를 클라이언트에게 회신하기 위한 서버자원을 사용하도록 공격

10. DRDOS (Distributed Reflection DOS)
: 공격자는 출발지 IP를 공격대상의 IP로 위조하여 다수의 반사서버로 요청정보를 전송,
  공격대상은 반사서버로 부터 다수의 응답을 받아 서비스 거부상태가 됨

  * 공격근원지를 파악하기 어렵다. (출발지 IP를 변조하여, 공격트래픽이 수많은 반사서버를 경유하므로)
  * 좀비PC의 공격트래픽 효율이 증가한다. 반사서버는 syn+ack 패킷에 대한 응답이 없는경우 일정횟수 재전송을
    수행하기 때문에 공격자가 전송하는 syn패킷보다 몇배많은 syn+ack 패킷이 타켓에 전송된다.

** 해결방법
: IP주소가 위조된 패킷이 인터넷망에 유입되지 않도록 ISP가 직접 차단
  반서서버에게는 icmp프로토콜이 필요없는 시스템은 해당프로토콜을 차단

1. ls (디렉터리, 파일 정보 출력)
-> 1) 파일종류, 접근권한  2) 하드링크수  3) 소유주  4) 소유그룹  5) 크기  6) 최종 변경일  7) 최종 변경시간  8) 이름

2. stat (i-node 속성정보 출력)
-> 1) i-node number  2) 파일타입  3) 접근권한  4) link count  5) 소유자  6) 소유그룹  7) 크기  8) MAC Time  
    9) Block Index
    ln source_file target_file : 하드링크 
    ln -s source_file target_file : 심볼릭링크 (소프트 링크)

3. find (파일 검색)
-> find path [expression] [action]
    1) find . -name "*.c" : 현재 디렉터리에서 파일명이 .c로 끝나는 파일 검색
    2) find . -size +56 : 현재 디렉터리에서 파일 크기가 56블록보다 큰 것을 검색
    3) find . -perm -664 : 현재 디렉터리에서 user와 group에 읽기 및 쓰기 권한, other에 읽기 권한이 있는 파일 검색
    4) find . -mtime +3 : 현재 디렉터리에서 파일을 수정한지 3일이 지난 것을 검색

4. touch : 0byte 파일을 생성 또는 파일의 시간을 변경

5. umask : 파일 생성 시 접근권한에 영향을 미침 (/etc/profile 에 적용, 개인은 .profile에 적용)

6. diff : 파일이 동일한지 여부를 검사

7. comm : 파일을 비교할 때 사용 (한쪽에만 있거나 양쪽 모두에 있는 행 출력)

8. grep : 파일 내 특정 패턴이나 문자열을 검색

9. ps : 시스템에 상주중인 프로세스 정보 출력
-> UID, PID, PPID, STIME(프로세스 시작 시간), TTY(프로세스가 연결된 터미널), TIME(CPU 사용시간), CMD(프로세스명)

10. 시그널 : UNIX 시스템에서 지원하는 소프트웨어 인터럽트, 프로세스간 통신수단
-> 1) 외부에 의해서 : 키보드 입력 (ctrl + c)
    2) (커널)에러에 의해서 : divde zero 오류, 메모리 참조 오류
    3) 이벤트에 의해서 : alarm() 함수, 프로세스 종료
    4) 인위적으로 : kill() 함수, kill 명령어 (kill -시그널번호 PID)
  * 주요시그널 : SIGKILL(9), SIGSTOP(23) 이 2가지는 무시나 핸들링이 불가능하므로 관리자가 해커를 막기위한 강력권한
  * 좀비프로세스 : 프로세스 수행을 종료했지만 부모 프로세스가 종료상태정보를 확인하지 않아서 소멸하지 않고
                        남아있는 프로세스
  * 고아프로세스 : 자식프로세스가 살아있는 상태에서 부모 프로세스가 종료하게 되면 자식프로세스는 고아프로세스 됨.

11. mount : 보조기억장치에 설치된 파일시스템을 UNIX시스템이 인식하도록 특정 디렉토리에 논리적으로 연결시킴

12. cron : 정기적 처리할 작업을 crontab명령으로 crontab파일에 저장, cron데몬 프로세스가 관리
              해커가 주기적으로 정보를 빼돌리는 데에 사용도 가능하다. -> crobtab 파일 관리 필요

13. /etc/passwd : account / password(x로표시) / user_ID / group_ID / comment / home_directory / login_shell
    /etc/shadow : account / encrypted_password / last_change / minlife / maxlife / warn / inactive / expires
      ** chage 명령어로 패스워드 Aging관련 설정을 할 수 있다. -> /var/log/secure파일에 로그가 남는다.

14. setuid, setgid (chmod ug+s)
   1) setuid, setgid 설정된 경우 -> RUID == EUID,  RGID == EGID
   2) setuid, setgid 설정되지 않은 경우
   -> RUID, RGID = 실행시킨 사용자의 ID
       EUID, EGID  = 실행파일 소유자의 ID (프로세스가 실행중인 동안에 접근권한을 판단하기 위한 ID)
* root소유의 실행파일에 setuid를 설정하면, ruid는 실행자의 id, euid는 root id로 설정이 된다. 
  따라서, 실행 프로그램 내에 euid 설정에 따라 root권한으로 접근하게 된다.

* sticky bit (chmod o+t)
-> 디렉토리에 설정이 되면, 파일의 생성은 자유롭게 할 수 있지만
    파일 삭제 및 파일명 변경은 파일소유자 또는 root만이 가능하다.

암호화를 통한 정보보안 방법은 계속 발전해왔습니다.

--> 스테가노그라피(최근엔 워터마크) -> 전치 -> 단일치환 -> 다중치환 (에그니마) -> DES -> AES -> RSA -> 양자암호학

DES : 페이스텔 구조
AES : SPN 구조

블록암호 원리 : 특정 비트 수의 집합을 한 번에 처리하는 암호 알고리즘
스트림암호 원리 : 음성, 영상 스트리밍 전송, 무선 암호화 방식 (평문 XOR 키 스트림)

대칭키 -> 키배포문제 -> Diffie-Hellman 키교환 -> 공개키 암호화

hash(무결성 확인)
-> MAC(메세지인증코드, hash + 대칭키암호 이용) -> 2명만이 키 공유하고 있으므로 거짓행세는 해결
-> 부인방지 문제 -> hash + 공개키 암호를 이용하는 전자서명으로 부인방지 해결 -> 중간자 공격으로 공개키 공유 시 올바른지의 문제  
-> PKI도입(공개키 인증서)로 해결 (공개키에 전자서명을 하여 배포, 이 때의 전자서명은 인증기관에서 발급한 공개키로 확인가능, 그 공개키는 App에 포함되어있다. 브라우져 등)

PKI : 공개키 기반구조 라고 하며, 공개키 암호화 알고리즘을 이용하여, 암호화 통신을 하는 구조에서 공개키를 공유하여야 하는데, 이 때 공개키 공유 시 중간자 공격으로 잘못된 키가 공유되지 않도록 하기 위하여, 공개키를 전자서명 기술을 이용하여 공개키 인증서 형태로 공유합니다.  (공개키 + 공개키를 RSA와 hash알고리즘으로 만든 전자서명 형식의 데이터) 이 때 공개키 인증서는 보통 공개키 암호화알고리즘 + hash 알고리즘 형태로 구성된 전자서명 기술로 만들어집니다.

여기서의 전자서명은 CA의 서명입니다.

이 공개키 인증서는 이미 CA에서 인증된 기관이면, 그 공개키 인증서를 브라우져내에 인증할 수 있는 공개키 및 인증방법이 탑재되어 있습니다.  그러므로, 브라우져를 통해 공개키를 안전하게 입수 가능합니다.

* 인증서 표준 규격은 X.509

* 폐지된 인증서의 일련번호의 목록에 대해 인증기관이 전자서명을 붙인 것이 CRL (Certificate Revocation List)

ECC : 타원곡선 문제의 원리를 이용한 공개키 암호화 알고리즘, 1024비트의 RSA 키와 160비트의 ECC는 동일한 보안수준 정도로 ECC가 고속으로 암호/복호가 가능

** 암호알고리즘의 안정성평가
--> 대표적으로 NIST의 CMVP 가 있다.
--> 암호알고리즘->암호모듈->정보보호제품->응용시스템 순으로 평가한다.
--> CMVP는 암호기술의 적합성, 암호키운용 및 관리 물리적 보안 항목으로 평가한다.

* 평가기준 중요요소
1. 암호해독 비용이 암호화된 정보의 가치 초과
2. 암호해독 시간이 정보의 유효기간 초과

** 위험관리 = 보안정책 -> 위험분석 (위험분석 : 자산식별 -> 위협 및 취약점 평가 -> 위험의 측정)
    -> 대책 선택 -> 대책 구현 -> 잔여위험 수용

** 워터마크 -> 판매자정보를 은닉하고, 저작권표시 용도
** 핑거프린트 -> 구매자 추적정보를 은닉하고, 구매자 추적 용도

고객이 특정 홈페이지를 접속할 때 생성되는 정보를 담은 임시 파일로 크기는 4KB 이하로 작다. 쿠키는 애초 인터넷 사용자들의 홈페이지 접속을 돕기 위해 만들어졌다. 특정 사이트를 처음 방문하면 아이디와 비밀번호를 기록한 쿠키가 만들어지고 다음에 접속했을 때 별도 절차 없이 사이트에 빠르게 연결할 수 있다.

쿠키는 사용하는 웹브라우저가 자동으로 만들기도 하고 갱신하기도 하며 웹사이트로 기록을 전달하기도 한다. 따라서 개인의 사생활을 침해할 소지가 있다. 이용자가 인터넷에서 어떤 내용을 봤는지, 어떤 상품을 샀는지 등 모든 정보가 기록되기 때문이다. 온라인 광고업체들은 쿠키를 이용해서 인터넷 사용자의 기호 등을 수집·분석해 광고전략을 짜는 데 유용하게 활용해왔다. 

또 보안문제를 유발하기도 한다. 회원번호나 비밀번호 등이 유출될 가능성이 있기 때문이다. 그래서 마이크로소프트는 인터넷 익스플로러 5.0 이상에서는 쿠키 거부 기능을 첨가했다.

- [네이버 지식백과] 쿠키 [cookie] (두산백과) - 

* 웹 사이트는 해당 사이트에 쇼핑정보, ID, 암호, IP주소 등의 세션 정보를 기억하기 위해
  쿠키를 사용한다. 

  1. 임시 쿠키 : 인터넷 익스플로러가 실행하고 있는 시간만큼만 유효, 익스플로러가 종료되면 삭제된다.
  2. 영구 쿠키 : 인터넷 익스플로러 세션을 통해 하드디스크에 저장된다. 보존기간은 설정에 따라 다르다.

--> 익스플로러에서는 도구-인터넷옵션-개인정보 탭에서 보호정책 단계를 선택할 수 있다.

* 인터넷 익스플로러는 "InPrivate"모드를 통해 탭을 열어 쿠키정보 저장을 안하게 가능
* 크롬은 "시크릿"모드를 통해 탭을 열어 쿠키정보 저장을 안하게 가능