Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

오픈소스

윈드리버 - 보안 위협으로부터 리눅스 시스템 보호하기

오픈 소스 리눅스는 임베디드 시스템 및 장치를 개발하는 개발자 사이에서 인기가 많다. 그러나 배포되는 상호 연결된 임베디드 시스템 장치들의 수가 계속해서 증가하면서 리눅스 소프트웨어의 취약점이 그 어느 때보다 널리 확산되고 있다. 취약점을 식별하고 필요한 업데이트를 수행하여 위협을 완화하는 일은 장치 개발자 및 제조업체가 전부 감당하기 어려운 경우가 많다.  본 백서는 모니터링, 평가, 통보, 치료 등 리눅스 취약점 해결을 위한 검증된 4단계 프로세스에 대해 설명한다. 또한 기업이 취약점을 내부적으로 모니터링하고 수정하는 데 따르는 비용을 따져보고, 배포된 장치 및 시스템을 지속적으로 보호할 때 숙련된 보안팀과의 협업을 선택하는 것이 왜 보다 현명한 선택일 수 있는지 설명한다. <6p> 주요 내용 - 보안이 취약한 세상 - 틈에 주의하라 - 핵심 4단계 : 모니터링, 평가, 통보, 치료 - 보호 비용 - 윈드리버 리눅스 보안 대응 프로세스

오픈소스 리눅스 임베디드 5일 전

마이크로소프트의 오픈소스 SBOM 생성기 살펴보기

솔라윈즈(SolarWinds) 해킹 사건 이후, 기업은 CI/CD를 도입하는 과정에서 확인해야 할 것이 많아졌다. 사용자에게 배포하는 소프트웨어를 의도한 대로 구축하려면 어떻게 해야 하는가? 코드의 의존성이 모두 원하는 형태로 나타났는가? 서드파티 모듈을 사용하면 기대한 결과를 얻을 수 있는가? 같은 질문을 던져야 하는 것이다.    겹겹이 쌓인 코드와 의존성으로 시스템은 점점 복잡해지고 있다. 거기다 현대 시대의 개발자는 공개된 소스코드를 활용한다. 남이 만든 코드이지만 사람들은 그 소스코드를 있는 그대로 신뢰한다. 하이퍼텍스트라는 용어를 고안한 걸로 유명한 옥스포드대 교수 테드 넬슨의 표현처럼, 모든 기술이 이제 서로 심층적으로 얽히고설켜 있는 것이다. 이때 소스코드의 신뢰를 확인하기 위한 방안으로 SBOM이 떠오르고 있다.    SBOM이 필요한 이유 솔라윈즈 해킹 사건이 일어난 후 미국 행정부는 국가 사이버 보안을 높이겠다는 행정명령을 따로 발표하고 미 국립 표준기술연구소(National Institute of Standards and Technology)에게 관련 지침을 개발 및 배포하라고 지시했다. 해당 지침은 소프트웨어 공급망, 모듈 네트워크, 코드 개발에 사용되는 구성요소의 보안을 강화하는 방안을 골자로 하고 있으며, 현재 외부에 공개된 상태다. 이 문서는 기업에게 코드와 함께 소프트웨어 명세서(Software Bill of Material, SBOM)를 함께 제시하라고 요청하고 있다.  사실 SBOM은 새로운 것이 아니다. 마이크로소프트를 포함한 많은 기업이 기술 상세 정보를 사용자에게 제공하고 있었다. 대신 표준화된 문서는 없었으며, 기업마다 그 구조가 다 달랐고, 기계가 판독할 수 없는 형태이기도 했다. 그래서 마이크로소프트는 SBOM 스키마 표준을 개발하기 CISQ(Consortium for Information and Software Quality)라는 그룹과 협력했다. 미 정부가 SBO...

SBOM 오픈소스 2022.08.01

"C++의 기술적 부채 털자" 구글, 개발언어 '카본' 공개

‘C++’을 대체하기 위해 개발 중인 오픈소스 프로그래밍 언어 ‘카본(Carbon)’은 C++과 동일한 수준의 성능 그리고 호환성을 지원하는 한편, 기술적 부채와 고질적인 문제를 해결할 계획이다.  전 세계에서 가장 많이 쓰이는 프로그래밍 언어 중 하나인 ‘C++’의 후계자가 필요한 시점이라고 생각하는가? 구글의 개발자 그룹은 그렇다고 보고 있다.     해당 그룹은 C++과의 상호 운용성을 제공하는 동시에, 이 레거시 언어를 개선하는 데 있어 알려진 문제를 해결하는 실험적 프로그래밍 언어 ‘카본’을 개발하고 있다. 개발팀에 따르면 카본은 C 또는 C++이 수십 년간 쌓아온 기술적 부채를 상속하지 않으면서 최신 제네릭 시스템, 간단한 구문, 모듈식 코드 구성 등의 기반으로 시작해 앞서 언급한 장애물을 극복하려고 시도 중이다.  현재 카본은 사용 가능한 상태는 아니다. 카본 개발팀은 C++이 퍼포먼스 크리티컬 소프트웨어 구축에 지배적인 프로그래밍 언어이며, 방대한 코드 기반이 있다고 말했다. 이에 카본은 ‘진화’보다는 ‘후속 접근 방식’을 제시하며, 기존 C++ 코드 기반 및 C++ 개발자를 위한 마이그레이션을 지원할 것이라고 전했다.  카본은 지난주 캐나다 토론토에서 열린 개발자 컨퍼런스 ‘C++노스(CPP North)’에서 공개됐다. 카본의 리소스는 해당 프로젝트의 깃허브 리포지토리에서 액세스할 수 있다. 개발팀은 C++ 후계자로서의 요건을 다음과 같이 언급하면서, 카본의 접근 방식이 C++ 생태계 위에 구축될 수 있다고 밝혔다.    C++과 동일한 수준의 성능 C++과의 원활한 상호 운용성 완만한 학습 곡선 비슷한 표현식 확장 가능한 마이그레이션  카본은 타입스크립트가 자바스크립트, 코틀린이 자바와 비슷한 것처럼 C++과 유사하게 설계됐다. 개발팀은 카본이 퍼포먼스 크리티컬 소프트웨어, 소프트웨어 및 언어 발전을 지원하고, 안전하며 읽기 및 쓰기가 쉬운 코드를 ...

C++ 카본 구글 2022.08.01

깃가디언, 오픈소스 소프트웨어 위험 탐지 프로젝트 ggcanary 출범

코드 보안 플랫폼 제공업체 깃가디언(GitGuardian)이 침해된 개발자 및 데브옵스 환경을 탐지하기 위한 새로운 오픈소스 카나리아 토큰 프로젝트를 발표했다. 설명에 따르면 기업 보안 팀은 깃가디언의 카나리아 토큰(ggcanary)을 사용해서 아마존 웹 서비스(AWS)의 비밀 정보 형식으로 카나리아 토큰을 만들어 배포할 수 있으며, 공격자가 토큰을 변조하는 즉시 경보를 트리거할 수 있다. 깃가디언의 이번 발표는 소프트웨어 공급망 및 데브옵스 툴과 관련한 위험에 대처하기 위한 여러 표준과 이니셔티브가 등장하는 업계 추세를 반영한다.     ggcanary의 특징은 “고도로 민감한” 침입 탐지 보도자료에서 깃가디언은 클라우드 및 현대 소프트웨어 개발 방식의 도입이 지속되면서 기업이 모르는 사이 공격 표면이 확장되고 있다고 말했다. 또한 인터넷에 대면한 자산과 기업 네트워크가 적절히 보호되지 않을 경우 공격자는 지속적 통합 및 지속적 배포(CI/CD) 파이프라인과 같은 소프트웨어 공급망 구성요소를 진입점으로 노리게 된다고 덧붙였다.   깃가디언의 연구에 의하면 공격자가 첫 액세스 권한을 획득한 후 취하는 일반적인 행동은 횡적 이동에 사용할 수 있는 하드 코딩된 유효한 인증 정보를 찾는 것이다. 깃가디언은 ggcanary 프로젝트가 기업에서 침해를 더 신속하게 탐지하도록 설계됐다면서 다음과 같은 특징을 설명했다.   테라폼(Terraform)에 의존. 하시코프(HashiCorp)가 개발한 인기 있는 코드형 인프라 소프트웨어 툴을 사용해서 AWS 카나리아 토큰을 생성하고 관리 AWS 클라우드트레일(CloudTrail) 감사 로그를 사용해서 공격자가 카나리아 토큰에서 수행한 모든 유형의 작업을 추적하는 고도로 민감한 침입 탐지 조직의 내부 경계, 소스 코드 리포지토리, CI/CD 툴, 티켓팅, 메시징 시스템(지라, 슬랙, 마이크로소프트 팀즈 등)에 최대 5,000개의 활성 AWS 카나리아 토큰을 배포할 수 있는 확장성 A...

오픈소스 데브옵스 카나리아토큰 2022.07.29

"선택 아닌 필수" SBOM을 작성하는 베스트 프랙티스와 추천 프로그램 8선

소프트웨어를 실제로 보호하려면 코드 안에 무엇이 있는지 알아야 한다. 그렇기 때문에 오늘날 소프트웨어 자재 명세서(Software Bill of Material, SBOM)는 필수적이다. 과거에는 코드 보안에 대해 크게 걱정하지 않았다. 어리석은 일이었다.   그리고 보안 문제가 잇따라 발생했다. 솔라윈즈 소프트웨어 공급망 공격, 여전히 진행 중인 Log4j 취약점 및 npm 메인테이너 항의 코드가 잘못된 사건으로 보안 업계는 소프트웨어 공급망을 정리해야 한다는 사실을 분명히 깨달았다. 독점 소프트웨어는 제작자가 프로그램 내부에 무엇이 있는지 알려주지 않으므로 불가능하다. 그러나 오픈소스 프로그램을 사용하면 SBOM(s-bomb으로 발음됨)으로 정리할 수 있다. 사실 SBOM은 더 이상 ‘하면 좋은 것’이 아니다. 미국에서는 연방정부의 명령이다. 미국 대통령 조 바이든이 2021년 7월 12일 발표한 ‘국가 사이버보안 개선에 관한 행정명령’에서는 SBOM이 요구사항에 포함된다. 행정명령은 SBOM을 ‘소프트웨어 구축에 사용되는 다양한 구성요소의 세부 사항 및 공급망 관계를 포함하는 공식 기록’으로 정의한다. ‘소프트웨어 개발자와 공급업체는 종종 기존 오픈소스 및 상용 소프트웨어 구성요소를 조립하여 제품을 만드는 경우가 많다’는 점 때문에 오픈소스 소프트웨어에서 특히 중요한 문제다. 그렇다. 오픈소스 소프트웨어가 모든 곳에서, 모든 것을 위해 사용된다는 것은 모두가 안다. 하지만 오픈소스 구성요소를 포함한 애플리케이션이 무려 92%에 달한다는 사실을 알고 있었는가? 사실 평균적인 현대 프로그램은 70%가 오픈소스 소프트웨어로 구성되어 있다.  분명히 조치가 필요하다. 리눅스 재단과 오픈소스 보안 재단(Open Source Security Foundation, OpenSSF), 오픈체인(OpenChain)에 따르면 정답은 SBOM이다. 리눅스 재단의 연구 담당 부사장 스티븐 헨드릭은 SBOM을 다음과 같이 정의한다.   ...

SBOM 추천 오픈소스 2022.07.27

"돈이 아닌 교육ㆍ기술 찾아 떠난다⋯오픈소스 개발자 44%는 이직 고려 중"

'대퇴직(Great Resignation)' 시대, 오픈소스 개발자 상당수가 이직의 기회를 찾고 있는 것으로 나타났다. 데이터베이스 관리 소프트웨어 업체 EDB가 전 세계 1,400명 이상의 오픈소스 애플리케이션 개발자와 IT 운영자, 관리자를 설문조사했다. 그 결과 응답자의 44%는 어느 정도 현재 직장에 만족하고 있지만 여전히 이직을 고려 중인 것으로 나타났다. 응답자의 10%는 현재 직장에 만족하지 않는다고 답했고, 현재 업무에 만족한다는 응답은 46%였다. 많은 오픈소스 개발자가 이직 기회를 노리는 이유는 단순히 급여나 복지가 아니다. 오히려 경력을 한 단계 업그레이드하거나 적절한 멘토십이나 더 좋은 교육의 기회를 찾아 이직한다는 응답이 더 많았다. 응답자의 67%는 지난 1년 사이 할당된 업무량이 늘었다고 답했다. 실제로 응답의 약 43%는 새로운 직장을 찾는 가장 큰 이유로 경력 관리를 꼽았다. 2021년 초 진행했던 설문에서 같은 질문에 경력 관리를 꼽은 비율은 24%였는데 1년 사이에 크게 늘었다. 또한, 조사 결과를 보면, 응답자의 거의 32%가 더 최신 기술을 이용해 일할 기회를 찾아 이직을 고려 중인 것으로 나타났다. 지난해 조사의 16%에서 2배로 늘어났다. 또한 응답자의 약 38%는 더 좋은 멘토십을 받을 수 있는 직장으로 이직하는 것을 고려 중이라고 답했고, 30%는 더 좋은 교육과 자격증 과정을 제공하는 곳으로 이직하고 싶다고 답했다. 한편 현재 직장에 만족한다는 응답자 중 약 21%는 현재 직장이 멘토링 프로그램을 실시하고 있다고 답했다. 반면 현재 직장에 불만족하는 응답자의 43%는 현재 직장이 지난 1년 동안 어떤 원격 교육이나 멘토링 프로그램을 실행하지 않았다고 답했다. 보고서는 현재 직원을 계속 근속시키려면 기업은 직업의 경력을 업그레이드할 수 있는 정책을 실행하는 것은 물론, 더 좋은 멘토십과 교육 기회를 적절하게 시행해야 한다고 조언했다. editor@itworld.co.kr

오픈소스 이직 2022.07.25

"개발자에 좋은 것은 해커에게도 좋다" 오픈소스 SW 공급망 보안 문제의 해법

소프트웨어 공급망 보안에 대한 권한은 누가 가져야 할까? 개발자 혹은 개발자를 지원하는 플랫폼과 보안 엔지니어링 팀? 과거에는 기업의 지원 계약 및 보안 서비스수준협약(SLA)을 어느 리눅스 배포판과 운영체제, 인프라 플랫폼으로부터 확보할지를 CIO, CISO, 또는 CTO와 담당 보안팀이 결정하곤 했다. 하지만 이후 개발자가 이 모든 일을 도커 파일(Docker Files)과 깃허브 액션(GitHub Actions)에서 처리하게 됐다. 개발자에게 상황이 ‘시프트 레프트(shift left)’했고 이전과 같은 기업 차원의 감독은 사라졌다.   오늘날에는 규정 준수 및 보안 팀이 이런 정책과 요건을 규정한다. 개발자는 이 요건을 준수하는 범주 내에서 원하는 도구를 선택할 유연성을 갖는다. 이처럼 업무가 구분되면 개발자 생산성에 가속도가 크게 붙는다. 그러나 Log4j 사태는 기업의 시스템 보안 문제에 대한 경종을 울렸다. 시프트 레프트 개발자 자율성과 생산성의 장점에도 불구하고 소프트웨어 공급망을 이루는 오픈소스 구성요소는 악성 행위자가 노리는 새로운 표적이 되고 말았다.   오픈소스는 개발자와 공격자 모두에게 좋다 네트워크 보안은 공격자 입장에서 예전보다 훨씬 더 어려운 공격 벡터가 됐다. 반면 오픈소스라면? 오픈소스 의존성 또는 라이브러리를 찾아 개입한 후 다른 모든 의존성으로 방향을 전환하면 그만이다. 공급망은 기업과 기업의 소프트웨어 산출물 사이의 연결 고리가 중요하다. 오늘날 공격자는 바로 이 부분을 집중적으로 공략하고 있다. 기본적으로 개발자 입장에서 오픈소스 소프트웨어의 장점은 공격자 입장에서도 장점이다. 개방성 : 개발자는 ‘누구나 코드를 볼 수 있고 누구나 코드에 기여할 수 있다’는 점을 좋아한다. 리누스 토발스의 말처럼 “지켜보는 눈이 많으면 모든 버그는 잡아내기 쉬워지고” 이는 오픈소스의 큰 장점이다. 반면 공격자는 ‘깃허브 계정이 있는 사람이라면 누구나 필수 라이브러리에 코드에 기여할 수 있다’는 점을 대단히 좋아...

오픈소스 보안 2022.07.22

글로벌 칼럼 | AI 시대 필요한 것은 오픈‘소스’가 아닌 오픈소스 ‘접근권’

기술 업계는 오픈소스와 개방성이 정확히 무엇을 의미하는지 다시 논의해볼 필요가 있다. 필자는 2006년 오스콘(OSCON) 컨퍼런스에서 이미 비슷한 질문을 던졌고 당시 패널이었던 구글과 야후 직원에게 “왜 의미 있는 오픈소스를 공개하지 않느냐”고 따진 적 있다. 팀 오라일리는 블로그를 통해 이 문제를 따로 언급하며 “클라우드 시대에는 오픈소스 기술을 공유할 동기가 사라졌다. 프로그램 실행할 때 사본 파일은 필요 없고 서비스 접근 권한만 주면 된다. 필요하지 않을 뿐 아니라 대형 애플리케이션의 경우 사본을 주는 것 자체가 이제 불가능하다”라고 지적했다.   프로그램을 공유하는 것이 불가능해지면서 지난 10년간 오픈소스라는 정의는 점점 모호해지고 있다. 오라일리 미디어의 부사장 마이크 루키데스는 최근 블로그를 통해 “오픈소스를 바라보는 시선이 인공 지능(AI) 기술에도 영향을 미치고 있다”라며 “AI에서 처리하는 데이터 규모가 너무 방대하기 때문에, 오픈소스가 있어도 대형 언어 모델을 활용하기는 상당히 힘들다”라고 밝혔다.  2006년 클라우드 시대와 비슷하게, AI 시대에 오픈소스를 전통적인 방식으로 공개하려 한다면 여러 문제를 겪을 수 있다. 그렇다고 해서 오픈소스 공개가 의미 없다는 뜻은 아니다.   특별한 하드웨어가 필요한 오픈소스 루키데스에 따르면 많은 업체가 AI 기술에 관여하고 있지만 실질적으로 AI 산업을 주도하는 업체는 페이스북, 오픈AI(OpenAI), 구글이다. 이들의 공통점은 무엇일까? 방대한 모델을 대규모로 운용할 수 있는 능력이 있다는 점이다. 다시 말해, 일반적인 기업은 불가능한 방식으로 AI를 개발하고 있다. 그런 사실을 굳이 숨기지도 않으며, 세 업체는 필자 같은 일반인은 모르는 인프라와 운영 지식을 보유하고 있다.  루키데스는 “페이스북이 만든 OPT(Open Pretrained Transformer)-175B의 소스 코드는 누구나 다운로드할 수 있다. 하지만 이 모델을 다운받고 훈련할 만...

오픈소스 인공지능 2022.07.21

'RHEL 기반 무료 배포판' 록키 리눅스 9.0 버전 공개

레드햇 엔터프라이즈 리눅스(RHEL; Red Hat Enterprise Linux)의 소스 코드를 사용해 만든 무료 리눅스 배포판이자 오픈소스 엔터프라이즈 OS ‘록키 리눅스(Rocky Linux)’의 최신 릴리즈가 GA 버전으로 출시됐다. 이번 업데이트에는 새로운 보안 및 네트워크 기능과 ‘페리도트(Peridot)’라는 새 오픈소스 빌드 시스템이 추가됐다.    지난 7월 14일(현지 시각) 공개된 ‘록키 리눅스 9.0’는 개발자가 커뮤니티 또는 업스트림 지원 조직과 독립적으로 무언가 하려는 경우, 록키 리눅스를 선택하거나 OS를 확장 혹은 재생산할 수 있는 모든 빌드 체인 인프라 도구를 제공한다. 새로운 클라우드 네이티브 빌드 시스템 개발의 목표는 새 RHEL 버전 출시 후 일주일 이내에 록키의 새 버전이 출시될 수 있도록 하는 것이라고 프로젝트 담당자는 밝혔다.  페리도트의 소스 코드는 깃허브에서 확인할 수 있으며, 머지않아 헬름(Helm) 차트를 통해 쉽게 설치할 수 있을 것이라고 회사 측은 전했다. 록키 리눅스는 이곳에서 다운로드할 수 있다. 록키 엔터프라이즈 소프트웨어 재단(RESF)에서 호스팅하는 록키 리눅스는 센트OS(CentOS) 공동 창시자이자 CIQ의 CEO 그레고리 커처가 센트OS의 (원래) 목표인 RHEL의 프로덕션 레디 다운스트림 버전을 제공하기 위해 개발했다.  CIQ에서 개발하고 RESF에서 제공하는 페리도트는 록키 리눅스를 구축 및 관리하기 위한 클라우드 네이티브 스택 역할을 한다. 이 스택은 오픈소스로 출시됐다. 록키 리눅스는 오픈소스 도구를 사용하여 센트OS 수명 종료 문제가 반복되지 않도록 ‘재생산 가능한(reproducible)’ 운영체제를 제공한다. 이 밖에 록키 리눅스 9.0의 새로운 기능 및 변경 사항은 다음과 같다.    SE리눅스(SELinux) 성능, 메모리 오버헤드, 로드 시간이 개선됐다.  현재 버전 3.0.1인 오픈SSL(OpenS...

록키 리눅스 리눅스 리눅스 배포판 2022.07.18

스타록스, ‘아파치 도리스’ 기반 실시간 분석 서비스 공개

데이터 분석 서비스 신생 업체 스타록스(StarRocks)가 오픈소스 기술 아파치 도리스(Doris)를 활용한 관리형 DBaaS(database-as-a-service)를 14일 공개했다.    새로 공개된 클라우드 기반 서비스는 기존 스타록스의 SQL 엔진 기술과 호환되며, MMP(Massively Parallel Processing) 데이터 웨어하우스의 완전 관리형 버전으로 제공된다. 주로 온라인 트랜잭션 처리(OLAP) 워크로드 관련 업무에서 활용할 수 있다. 스타록스는 “기존 서비스보다 가격을 낮추면서 쿼리 반환 속도를 높였다”라고 설명했다.  스타록스는 2020년 중국 바이두 출신 직원이 모여 만든 기업으로, 작년 2월 시리즈 B 형태로 4,000만 달러 규모의 투자를 받은 바 있다. 지금까지 유치한 총투자 금액은 6,000만 달러다.  아파치 도리스 역시 바이두에서 광고 분석을 위해 만든 데이터 웨어하우스 시스템이다. 2017년 오픈소스로 전환됐으며, 아파치 재단이 2018년부터 관리하다가 지난달 아파치 최상위 프로젝트로 승격됐다.  스타록스의 전략 부문 부사장 리 캉은 “경쟁 기술인 클릭하우스(ClickHouse)와 아파치 드루이드(Druid)는 이미 북미시장에서 이미 인기가 높다”라며 “관리형 서비스로 북미 시장에서 경쟁력을 높일 것”이라고 밝혔다.  새 서비스의 요금은 데이터 및 컴퓨팅 자원 사용량에 따라 실시간으로 내는 방식과 사전에 비용을 한꺼번에 내는 방식 중 선택할 수 있다. 사용자는 기존에 보유한 데이터 및 인프라를 이번 분석 도구와 통합할 수도 있다. 스타록스는 올해 3분기 안에 AWS를 지원하고 이후 구글 클라우드 플랫폼과 호환할 수 있도록 작업할 계획이다.  editor@itworld.co.kr

도리스 오픈소스 스타록스 2022.07.15

기초부터 다시 시작하는 리눅스 : 기본 활용편 - HowTo

전 세계에서 운영되는 웹사이트 10개 중 4개 정도가 리눅스를 사용한다. 500가지 이상의 배포판이 나왔고, 광범위한 안드로이드 기기와 각종 슈퍼 컴퓨터에서 쓰이는 것은 물론 심지어 화성에서 운행 중인 탐사차 '퍼서비어런스'에도 리눅스가 들어갔다. 이처럼 리눅스는 등장한 지 30년이 넘었지만 여전히 가장 중요한 운영체제로 꼽히고, 기업의 IT 환경에서는 더 그렇다. 인프라 운영부터 앱 개발까지 필수 기술로 자리 잡은 리눅스를 기초부터 차근차근 쉽게 접근할 수 있도록 안내한다. 지금부터 리눅스 기본 활용 방법을 중심으로 살펴보자. 주요 내용 - 명령어 정보를 찾는 명령어 3총사 - 리눅스용 최고의 셸 프로그램 ‘배시’ 기초 가이드 - "윈도우도 괜찮아" 브라우저에서 리눅스 터미널 사용하기 - 리눅스 true, false 명령어의 숨겨진 진실 - "네가 쓴 명령어를 알고 있다" 리눅스의 hash 사용법 총정리 - 리눅스에서 수치 연산 함수를 사용하는 방법 - "함께 하면 더 강력하다" 파이프로 여러 명령어 동시에 실행하기  

Linux 리눅스 오픈소스 2022.07.13

RHEL 9 리뷰 | 보안ㆍ관리 기능 강화한 기업용 리눅스 대표주자

레드햇 엔터프라이즈 리눅스(RHEL)의 최신 릴리스인 RHEL 9.0이 나왔다. 엔터프라이즈 서버와 클라우드 환경을 위한 더 견고한 보안을 지원하고 설치, 배포, 관리 기능도 개선됐다.   RHEL 9.0의 코드명은 '플로우(Plow)'다. RHEL 8.0 대비 큰 폭의 업그레이드로, 이를 이용하면 애플리케이션 개발자가 컨테이너를 더 쉽게 테스트하고 배포할 수 있다. 서버와 데스크톱 버전으로 제공되며, 안정성과 신뢰성, 견고함을 바탕으로 엔터프라이즈 워크로드를 위한 주요 리눅스 배포판이라는 위상을 잘 유지하고 있다. 소프트웨어 개발 용도로는 무료지만 인스턴스를 사용하려면 레드햇 구독 관리(RHSM) 서비스에 등록해야 한다. IBM의 자회사인 레드햇은 연중무휴 24시간 구독 기반 고객 지원과 전문 통합 서비스를 제공한다. 이렇게 구독을 통해 벌어들이는 수익으로 RHEL 자체에 포함되는 업스트림 기능을 비롯한 다른 오픈소스 프로젝트를 지원한다.   RHEL 9가 우리 기업 환경에 맞을까 RHEL 9는 다양한 물리적 하드웨어에서 실행하거나 하이퍼바이저의 가상머신, 컨테이너, 또는 서비스형 인프라(IaaS) 퍼블릭 클라우드 서비스의 인스턴스로 실행할 수 있다. 레거시 x86 하드웨어와 64비트 x86_64-v2, aarch64, ARMv8.0-A 하드웨어 아키텍처는 물론 IBM 파워 9, 파워 10, Z-시리즈(z14) 하드웨어 플랫폼을 지원한다. 보편적인 Ext4 파일 시스템, GFS2와 XFS를 포함한 다양한 데이터 스토리지 파일 시스템을 지원하고, Ext2, Ext3, vfat(FAT32)을 위한 레거시도 마찬가지다. RHEL은 대규모 영구 및 단기 저장 공간을 확장할 수 있는데 RHEL 9에서는 x86_64 아키텍처를 위한 최대 메모리 용량이 48TB로 늘었다.   RHEL 9 설치하기 RHEL 9를 설치하려면 먼저 운영체제를 다운로드해 간단한 몇 가지 단계를 따른다. RHEL 9를 설치할 때 '소프트웨어 선택(Software...

레드햇 RHEL 리눅스 2022.07.13

글로벌 칼럼 | ‘경기 침체가 오히려 호황기’ 오픈소스 개발자여, 지금이 기회다

고용 불안정을 벗어나고 싶다면, 오픈소스 소프트웨어와 가깝게 지내야 할 때다. 오픈소스 프로젝트를 활용하는 회사에 취업하거나 프로젝트 커뮤니티에 직접 기여해라.    경기 침체기에 진입한 것일까? 월스트리트의 저널(WSJ)의 대답은 ‘애매모호하다’라고 표현할 수 있다. 해당 매체는 지난 4일(현지 시각) ‘만약 미국이 경기 침체기에 접어든 것이 사실이라면, 이는 매우 독특한 형태의 경기 불황이다(If the U.S. is in a Recession, It’s a Very Strange One)’라는 제목의 기사를 게재하며 이런 투의 해석을 내놓았다. 경제의 총생산량이 하락했음에도 채용 시장은 아직 활발한 움직임을 보이고 있기 때문이라고 기사는 설명했다.  하지만 해당 기사는 벌서 2달 전인 5월의 경제 지표를 분석한 결과다. 현재 미국 테크 업계의 분위기는 심상치 않다. 최근 테크 기업이 신규 채용을 줄이고 심지어 정리해고를 단행하고 있기 때문이다. 항상 낙관적인 전망으로 가득 차 있는 벤처 투자 업계조차도 위험 부담이 큰 장기적인 투자 대신 단기수익 포트폴리오에 관심을 더 쏟고 있는 형국이다.  닷컴버블과 2008년 금융위기 같은 우여곡절을 겪은 세대에게 이런 광경은 역사의 반복처럼 느껴진다. 이런 경제난에 기업은 항상 비슷한 행태를 보인다. 투자를 진행하지만 대상을 선정하는 데 더 까다로워진다. 아울러, 오픈소스 소프트웨어에 더 많이 의존하게 되는 경향을 띠기 시작한다. 따라서 만약 고용 불안감에 허덕이고 있다면, 오픈소스가 원하는 기업으로 들어가는 길을 열여주는 '입장권'이 될 수 있을지도 모른다.  경기 침체에도 ‘끄떡없는’ 오픈소스  필자는 2007년에 한 가지 예측을 했다. 오픈소스가 “효율성을 최우선으로 설계되어 불황이 닥쳐도 가장 타격을 덜 받을 것”이라고 말했다. 그리고 오늘날, 이 예측은 맞아떨어졌다. 이를 증명할 만한 수치는 없지만, 오픈소스 기반 서비스 제공업체는 경기 불황 속...

오픈소스 오픈소스커뮤니티 경기침체 2022.07.13

시높시스, ‘2022 오픈소스 보안과 리스크 분석’ 연례 보고서 발간

시높시스는 전세계 오픈소스 사용 현황을 분석한 ‘2022 오픈소스 보안과 리스크 분석(OSSRA)’ 연례 보고서를 발표했다. 올해로 7번째 발간된 이번 보고서에는 OSS 라이선스 관리 솔루션인 ‘블랙덕 오딧 서비스(Black Duck Audit Services)’를 통해 실시한 전세계 17개 산업 분야의 2,400여 개의 커머셜 코드 베이스에 대한 분석이 담겨 있다.  이 보고서는 상호 연결된 소프트웨어 생태계에 대한 개발자들의 이해를 돕고, 관리되지 않는 오픈소스의 위험성, 보안 취약점, 오래된 구성요소, 라이선스 컴플라이언스 이슈에 대한 상세 정보를 전달한다.   2022 OSSRA 보고서에 따르면, 오픈소스가 모든 산업에서 널리 사용되고 있으며 현재 운영되고 있는 대부분의 애플리케이션에 기반을 제공하는 것으로 나타났다.   주요 내용은 ▲최악의 취약점으로 꼽히는 로그4j(Log4j) 등 오래된 오픈소스들이 여전히 표준으로 사용 ▲오픈소스 취약점이 전반적으로 감소 ▲라이선스 충돌도 감소하는 추세 ▲20%는 라이선스가 없거나 사용자 정의된 라이선스가 있는 오픈소스 등이다.  보고서에 따르면, 운영 리스크/유지보수 측면에서 2,097개의 코드베이스 중 85%가 4년 이상 지난 오픈소스를 포함하고 있는 것으로 나타났다. 88%는 사용 가능한 최신 버전이 아닌 구성 요소를 사용하고 있으며, 이중 5%에 취약한 버전의 로그4j가 포함돼 있다. 고위험 오픈 소스 취약점을 포함하는 코드베이스의 수는 대폭 감소했다. 올해 감사를 실시한 코드베이스 중 49%가 지난해 60%에 비해 최소 1개 이상의 고위험 취약점을 포함하고 있었고, 평가 대상 코드베이스의 81%가 적어도 하나의 알려진 오픈소스 취약성을 포함하고 있는 것으로 조사됐다. 이는 2021년 OSSRA의 조사 결과 대비 3% 감소한 수치이다.   코드베이스의 절반 이상(53%)이 라이선스 충돌을 포함했으나, 이는 2020년의 65%에 비해 상당히 감소한 ...

시높시스 오픈소스 2022.06.30

오픈소스 MPP 데이터 웨어하우스, ‘아파치 도리스’란? 

‘그’가 누구이고, 어떤 학교에 다녔는지 궁금한가? ‘아파치 도리스(Apache Doris)’는 아파치 인큐베이터(Apache Incubator)에서 개발한 오픈소스 MPP 분석 데이터 웨어하우스다. 지난주 아파치 소프트웨어 재단(Apache Software Foundation; ASF)은 도리스가 최상위 수준 프로젝트(Top-Level Project; TLP)로 승격했다고 발표했다.  MySQL 애널리틱스를 활용하는 이 SQL 기반 데이터 웨어하우스는 최근 버전 1.0 그리고 도리스를 다양한 애널리틱스 및 처리 기술과 연결하는 6개의 커넥터 릴리즈를 함께 출시했다(버전 1.0은 여덟 번째 릴리즈다). 특히 이는 데이터 과학 시나리오에서 자주 사용되는 온라인 분석 처리(OLAP) 워크로드를 지원하기 위해 개발됐다.  도리스는 중국의 인터넷 검색 대기업 바이두(Baidu)에서 태어났으며, 당시에는 ‘팔로(Palo)’라고 불렸다. 2017년 오픈소스화되고, 이어 2018년 아파치 인큐베이터에 기증되기 전까지 바이두의 광고 비즈니스를 위한 데이터 웨어하우징 시스템으로 사용됐다.    아파치 임팔라 및 구글 매사를 기반으로 하는 도리스 도리스는 구글 F1(Google F1)을 토대로 2012년 개발된 오픈소스 MPP SQL 쿼리 엔진 구글 매사(Google Mesa)와 아파치 임팔라(Apache Impala)의 기술 통합을 바탕으로 한다. 2014년경 확장성이 뛰어난 분석 데이터 웨어하우징 시스템으로 설계된 매사는 구글의 인터넷 광고 비즈니스와 관련된 중요한 측정 데이터를 저장하는 데 활용됐다.  바이두와 아파치 인큐베이터의 개발자에 따르면 이 데이터베이스는 고가용성, 안정성, 내결함성, 확장성은 물론 단순한 설계 아키텍처까지 제공한다. 아파치 소프트웨어 재단은 공식 성명에서 “단일 시스템(에서의 개발, 배포, 사용)과 많은 데이터 제공 요건을 충족하는 게 도리스의 주요 기능이다”라면서, “이 데이터 웨어하우수는...

오픈소스 데이터 웨어하우스 아파치 도리스 2022.06.27

컨테이너 분야의 '요즘 애들', 포드맨을 아시나요?

포드맨(Podman)은 ‘컨테이너 엔진’이다. 즉, 컨테이너 및 컨테이너 이미지를 개발, 관리, 실행하기 위한 도구다. 레드햇의 프로젝트인 포드맨은 지난 2019년 버전 1.0이 출시됐으며, 컨테이너 업계에서는 비교적 신참이다. 이후 포드맨은 약진을 거듭했으며, 오늘날의 컨테이너 세계를 만든 프로젝트인 도커(Docker)의 점진적인 쇠퇴로 이런 포드맨의 상승세가 더욱 부각되고 있다.    포드맨과 쿠버네티스 컨테이너 기반 개발을 조금이라도 안다면 ‘쿠버네티스(Kubernetes)’도 알 것이다. 컨테이너화된 애플리케이션이 점점 더 복잡해지면서 개발자는 다양한 가상머신, 심지어는 서로 다른 물리적 머신에서 실행되면서 상호작용하는 컨테이너를 조정할 수 있는 툴이 필요했다.  이런 툴을 ‘컨테이너 오케스트레이션 플랫폼’이라고 하는데, 그중 쿠버네티스가 가장 유명하다. 쿠버네티스는 오픈 컨테이너 이니셔티브(Open Container Initiative; OCI) 이미지 사양을 충족하는 모든 컨테이너에 사용할 수 있으며, 포드맨의 컨테이너도 마찬가지다. 쿠버네티스의 중요한 특징으로 ‘포드(pod)’ 개념이 있다. 포드란 쿠버네티스가 관리할 수 있는 최소의 컴퓨팅 단위인 하나 이상의 컨테이너를 임시로 그룹화한 것이다. 포드맨 역시 이름에서 알 수 있듯이 포드 개념을 기반으로 한다. 포드맨 포드에도 단일 네임스페이스, 네트워크, 보안 컨텍스트로 그룹화된 하나 이상의 컨테이너가 포함돼 있다. 이런 유사점 때문에 포드맨과 쿠버네티스는 자연스럽게 어울린다. 처음부터 레드햇의 목표는 포드맨 사용자가 쿠버네티스로 컨테이너를 오케스트레이션하는 것이었다. 포드맨 vs. 도커 컨테이너 세계에서 틀림없이 들어봤을 또 다른 거물급 이름은 도커다. 도커는 최초의 컨테이너 엔진은 아니지만, 여러 면에서 컨테이너화를 정의했다. 도커의 작동 방식 중 대부분이 컨테이너 기반 개발의 사실상 표준이고, 많은 사람이 컨테이너를 ‘도커’라고 부를 정도다. 도커...

컨테이너 도커 포드맨 2022.06.24

“보안도 왼쪽으로” 오픈소스 소프트웨어 위험과 시프트레프트 전략의 상관관계

오픈소스 소프트웨어는 대다수 애플리케이션에서 큰 비중을 차지하지만, 개발자와 보안 부서에는 보안 관련 과제를 던지는 존재다. 이번주 공개된 2종의 보고서에는 오픈소스 소프트웨어의 과제를 ‘시프트 레프트’ 전략을 확대 적용하면서 극복할 수 있다는 내용이 실려 주목을 끈다. 개발자 보안 업체인 스니크(Snyk)와 리눅스 재단은 ‘오픈소스 보안 현황(The State of Open Source Security)’ 보고서에서 10곳 중 4곳 이상의 기업(41%)이 오픈소스 보안에 확신이 없다고 지적했다. 또한 지난 3년 간 오픈소스 프로젝트에서의 취약점 수정 기간이 꾸준히 늘어 2018년(49일)보다 2021년(110일)에는 2배가 넘었다고 발표했다.     오픈소스에 대한 논쟁 : 생산성 vs. 보안 550명 이상의 응답자를 확보한 이번 보고서는 애플리케이션 개발 프로젝트의 취약점이 평균 49개, 일명 오픈소스 코드라고 칭하는 직접 의존성이 평균 80개라고 밝혔다. 그러나 오픈소스 소프트웨어 개발 또는 사용에 대한 보안 정책을 마련한 기업은 절반에 약간 못 미치는 49%였다. 규모를 중대형 기업으로 좁혀보면 이 수치는 27%에 지나지 않는다. 스니크 개발 관계 이사인 매트 저비스는 발표문에서 “오늘날 소프트웨어 개발사는 자체적인 공급망을 보유하고 있다. 자동차 부품을 조립하는 것처럼 자사만의 독특한 코드로 기존 오픈소스 구성요소를 이어서 코드를 조립한다. 생산성과 혁신을 대폭 개선할 수는 있지만 그만큼 보안 위험이 커진다는 단점이 있다”라고 지적했다.   "시프트 레프트로 취약점 조기 발견할 수 있어" 애플리케이션 자동화 테스트 업체 시프트 레프트(ShiftLeft) 역시 '애플리케이션 보안 발전(AppSec  Progress)' 보고서를 발행하면서 오픈소스 소프트웨어 보안 역시 시프트 레프트 전략, 또는 소프트웨어 개발 생명주기 시작을 조기에 앞당기는 것으로 보완할 수 있다고 주장했다. 보고서는 시프트레프트의 코어(Cor...

오픈소스소프트웨어 오픈소스 보안 2022.06.24

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.