▲ 중국 국가 표준화 관리위원회(国家标准化管理委员会, Standardization Administration of the P. R. C, SAC)) 홈페이지스위스 제네바에 본부를 두고 있는 국제표준화기구(ISO)에서 활동 중인 기술위원회(Technical Committeee, TC)는 TC 1~TC 323까지 구성돼 있다.기술위원회의 역할은 기술관리부가 승인한 작업범위 내 작업 프로그램 입안, 실행, 국제규격의 작성 등이다. 또한 산하 분과위원회(SC), 작업그룹(WG)을 통해 기타 ISO 기술위원회 또는 국제기관과 연계한다.ISO/IEC 기술작업 지침서 및 기술관리부 결정사항에 따른 ISO 국제규격안 작성·배포, 회원국의 의견 편집 등도 처리한다. 소속 분과위원회 및 작업그룹의 업무조정, 해당 기술위원회의 회의 준비도 담당한다.1947년 최초로 구성된 나사산에 대한 TC 1 기술위원회를 시작으로 순환경제를 표준화하기 위한 TC 323까지 각 TC 기술위원회의 의장, ISO 회원, 발행 표준 및 개발 표준 등에 대해 살펴볼 예정이다.이미 다룬 기술위원회와 구성 연도를 살펴 보면 △1947년 TC 1~TC 67 △1948년 TC 69 △1949년 TC 70~72 △1972년 TC 68 △1950년 TC 74 △1951년 TC 76 △1952년 TC 77 △1953년 TC 79, TC 81 △1955년 TC 82, TC 83 △1956년 TC 84, TC 85 △1957년 TC 86, TC 87, TC 89 △1958년 TC 91, TC 92 등이다.△1959년 TC 94 △1960년 TC 96, TC 98 △1961년 TC 101, TC 102, TC 104, △1962년 TC 105~TC 107, △1963년 TC 108~TC 111, △1964년 TC 112~TC 115, TC 117, △1965년 TC 118,  △1966년 TC 119~TC 122, △1967년 TC 123,  △1968년 TC 126, TC 127, △1969년 TC 130~136, △1970년 TC 137, TC 138, TC 142, TC 145, △1971년 TC 146, TC 147, TC 148, TC 149, TC 150, TC 153 등도 포함된다.ISO/TC 154 상업, 산업 및 행정 분야 프로세스, 데이터 요소 및 문서(Processes, data elements and documents in commerce, industry and administration)와 관련된 기술위원회는 1972년 결성됐다. 사무국은 중국 국가표준화관리위원회(国家标准化管理委员会, Standardization Administration of the P. R. C, SAC))에서 맡고 있다.위원회는 장 지안팡(Mr Jianfang Zhang)이 책임지고 있다. 현재 의장은 유 시(Mr Yu Shi)로 임기는 2024년까지다. ISO 기술 프로그램 관리자는 로라 매튜(Ms Laura Mathew), ISO 편집 관리자는 이본느 헨(Mrs Yvonne Chen) 등으로 조사됐다.범위는 비즈니스, 행정 프로세스의 국제 표준화 및 등록이다. 또한 개별 조직 내 및 조직간 정보 교환에 사용되는 지원 데이터의 국제 표준화 및 등록, 산업 데이터 분야의 표준화 활동을 지원한다.다음과 같은 애플리케이션별 메타 표준 개발 및 유지 관리도 포함된다.△프로세스 사양(다른 기술위원회의 개발이 없는 경우)△콘텐츠가 포함된 데이터 사양△양식 레이아웃(종이/전자)△표준 개발 및 유지 관리△프로세스 식별(다른 기술위원회의 개발이 없는 경우)△데이터 식별△EDIFACT 구문의 유지 관리현재 ISO/TC 154 사무국의 직접적인 책임 하에 발행된 표준은 37개며 SO/TC 154 사무국의 직접적인 책임 하에 개발 중인 표준은 7개다. 참여하고 있는 회원은 17개국, 참관 회원은 28개국이다.□ ISO/TC 154 사무국의 직접적인 책임 하에 발행된 표준 37개 중 15개 목록▷ISO 5054-1:2023 Specification for an enterprise canonical model — Part 1: Architecture▷ISO 6422-1:2010 Layout key for trade documents — Part 1: Paper-based documents▷ISO 7372:2005 Trade data interchange — Trade data elements directory▷ISO 8439:1990 Forms design — Basic layout▷ISO 8440:1986 Location of codes in trade documents▷ISO 8440:1986/Cor 1:2000 Location of codes in trade documents — Technical Corrigendum 1▷ISO 8601-1:2019 Date and time — Representations for information interchange — Part 1: Basic rules▷ISO 8601-1:2019/Amd 1:2022 Date and time — Representations for information interchange — Part 1: Basic rules — Amendment 1: Technical corrections▷ISO 8601-2:2019 Date and time — Representations for information interchange — Part 2: Extensions▷ISO 9735-1:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 1: Syntax rules common to all parts▷ISO 9735-2:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 2: Syntax rules specific to batch EDI▷ISO 9735-3:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 3: Syntax rules specific to interactive EDI▷ISO 9735-4:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 4: Syntax and service report message for batch EDI (message type — CONTRL)▷ISO 9735-5:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)▷ISO 9735-6:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 6: Secure authentication and acknowledgement message (message type - AUTACK)□ ISO/TC 154 사무국의 직접적인 책임 하에 개발 중인 표준 7개 목록▷ISO/WD 5909 Data interchange processes of blockchain based negotiable maritime bill of lading related to e-Commerce platform▷ISO/AWI 7372 Trade data interchange — Trade data elements directory▷ISO 8601-2:2019/DAmd 1 Date and time — Representations for information interchange — Part 2: Extensions — Amendment 1▷ISO/AWI 14533-3 Processes, data elements and documents in commerce, industry and administration — Long term signature profiles — Part 3: Long term signature profiles for PDF Advanced Electronic Signatures (PAdES)▷ISO/WD TR 19626-3 Processes, data elements and documents in commerce, industry and administration —Trusted communication platforms for electronic documents — Part 3: Blockchain-based implementation guideline▷ISO/DIS 20197-1 Buy-Ship-Pay Reference Data Model — Part 1: Business Requirement Specification (BRS)▷ISO/DIS 23355 Visibility data interchange between logistics information service providers

▲ 디지털 ID 산업의 발전 전략 [출처=iNIS]디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum,  CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.오픈ID(OpenID)는 개인 및 기업의 비영리 국제 표준화 조직으로 OpenID(개방형 표준 및 분산 인증 프로토콜)를 활성화, 홍보, 보호하기 위해 노력하고 있다.오픈ID 코넥트 코어(OpenID Connect Core)는 핵심 OpenID 기능을 정의하고 있다. OpenID 기능은 OAuth 2.0 기반에 구축된 인증과 최종 사용자에 대한 정보를 전달하기 위한 클레임의 사용이다.추가적인 기술 사양 문서는 검증 가능한 자격 증명 및 검증 가능한 프리젠테이션의 발급을 확장하기 위해 작성됐다. 또한 OpenID Connect 사용에 대한 보안 및 개인 정보 보호 고려 사항에 대해 설명하고 있다.아래는 오픈ID가 발행한 'OpenID Connect Core 1.0 incorporating errata set 1' 목차 내용이다.■목차(Table of Contents)1. Introduction1.1. Requirements Notation and Conventions1.2. Terminology1.3. Overview2. ID Token3. Authentication3.1. Authentication using the Authorization Code Flow3.1.1. Authorization Code Flow Steps3.1.2. Authorization Endpoint3.1.2.1. Authentication Request3.1.2.2. Authentication Request Validation3.1.2.3. Authorization Server Authenticates End-User3.1.2.4. Authorization Server Obtains End-User Consent/Authorization3.1.2.5. Successful Authentication Response3.1.2.6. Authentication Error Response3.1.2.7. Authentication Response Validation3.1.3. Token Endpoint3.1.3.1. Token Request3.1.3.2. Token Request Validation3.1.3.3. Successful Token Response3.1.3.4. Token Error Response3.1.3.5. Token Response Validation3.1.3.6. ID Token3.1.3.7. ID Token Validation3.1.3.8. Access Token Validation3.2. Authentication using the Implicit Flow3.2.1. Implicit Flow Steps3.2.2. Authorization Endpoint3.2.2.1. Authentication Request3.2.2.2. Authentication Request Validation3.2.2.3. Authorization Server Authenticates End-User3.2.2.4. Authorization Server Obtains End-User Consent/Authorization3.2.2.5. Successful Authentication Response3.2.2.6. Authentication Error Response3.2.2.7. Redirect URI Fragment Handling3.2.2.8. Authentication Response Validation3.2.2.9. Access Token Validation3.2.2.10. ID Token3.2.2.11. ID Token Validation3.3. Authentication using the Hybrid Flow3.3.1. Hybrid Flow Steps3.3.2. Authorization Endpoint3.3.2.1. Authentication Request3.3.2.2. Authentication Request Validation3.3.2.3. Authorization Server Authenticates End-User3.3.2.4. Authorization Server Obtains End-User Consent/Authorization3.3.2.5. Successful Authentication Response3.3.2.6. Authentication Error Response3.3.2.7. Redirect URI Fragment Handling3.3.2.8. Authentication Response Validation3.3.2.9. Access Token Validation3.3.2.10. Authorization Code Validation3.3.2.11. ID Token3.3.2.12. ID Token Validation3.3.3. Token Endpoint3.3.3.1. Token Request3.3.3.2. Token Request Validation3.3.3.3. Successful Token Response3.3.3.4. Token Error Response3.3.3.5. Token Response Validation3.3.3.6. ID Token3.3.3.7. ID Token Validation3.3.3.8. Access Token3.3.3.9. Access Token Validation4. Initiating Login from a Third Party5. Claims5.1. Standard Claims5.1.1. Address Claim5.1.2. Additional Claims5.2. Claims Languages and Scripts5.3. UserInfo Endpoint5.3.1. UserInfo Request5.3.2. Successful UserInfo Response5.3.3. UserInfo Error Response5.3.4. UserInfo Response Validation5.4. Requesting Claims using Scope Values5.5. Requesting Claims using the "claims" Request Parameter5.5.1. Individual Claims Requests5.5.1.1. Requesting the "acr" Claim5.5.2. Languages and Scripts for Individual Claims5.6. Claim Types5.6.1. Normal Claims5.6.2. Aggregated and Distributed Claims5.6.2.1. Example of Aggregated Claims5.6.2.2. Example of Distributed Claims5.7. Claim Stability and Uniqueness6. Passing Request Parameters as JWTs6.1. Passing a Request Object by Value6.1.1. Request using the "request" Request Parameter6.2. Passing a Request Object by Reference6.2.1. URL Referencing the Request Object6.2.2. Request using the "request_uri" Request Parameter6.2.3. Authorization Server Fetches Request Object6.2.4. "request_uri" Rationale6.3. Validating JWT-Based Requests6.3.1. Encrypted Request Object6.3.2. Signed Request Object6.3.3. Request Parameter Assembly and Validation7. Self-Issued OpenID Provider7.1. Self-Issued OpenID Provider Discovery7.2. Self-Issued OpenID Provider Registration7.2.1. Providing Information with the "registration" Request Parameter7.3. Self-Issued OpenID Provider Request7.4. Self-Issued OpenID Provider Response7.5. Self-Issued ID Token Validation8. Subject Identifier Types8.1. Pairwise Identifier Algorithm9. Client Authentication10. Signatures and Encryption10.1. Signing10.1.1. Rotation of Asymmetric Signing Keys10.2. Encryption10.2.1. Rotation of Asymmetric Encryption Keys11. Offline Access12. Using Refresh Tokens12.1. Refresh Request12.2. Successful Refresh Response12.3. Refresh Error Response13. Serializations13.1. Query String Serialization13.2. Form Serialization13.3. JSON Serialization14. String Operations15. Implementation Considerations15.1. Mandatory to Implement Features for All OpenID Providers15.2. Mandatory to Implement Features for Dynamic OpenID Providers15.3. Discovery and Registration15.4. Mandatory to Implement Features for Relying Parties15.5. Implementation Notes15.5.1. Authorization Code Implementation Notes15.5.2. Nonce Implementation Notes15.5.3. Redirect URI Fragment Handling Implementation Notes15.6. Compatibility Notes15.6.1. Pre-Final IETF Specifications15.6.2. Google "iss" Value15.7. Related Specifications and Implementer's Guides16. Security Considerations16.1. Request Disclosure16.2. Server Masquerading16.3. Token Manufacture/Modification16.4. Access Token Disclosure16.5. Server Response Disclosure16.6. Server Response Repudiation16.7. Request Repudiation16.8. Access Token Redirect16.9. Token Reuse16.10. Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)16.11. Token Substitution16.12. Timing Attack16.13. Other Crypto Related Attacks16.14. Signing and Encryption Order16.15. Issuer Identifier16.16. Implicit Flow Threats16.17. TLS Requirements16.18. Lifetimes of Access Tokens and Refresh Tokens16.19. Symmetric Key Entropy16.20. Need for Signed Requests16.21. Need for Encrypted Requests17. Privacy Considerations17.1. Personally Identifiable Information17.2. Data Access Monitoring17.3. Correlation17.4. Offline Access18. IANA Considerations18.1. JSON Web Token Claims Registration18.1.1. Registry Contents18.2. OAuth Parameters Registration18.2.1. Registry Contents18.3. OAuth Extensions Error Registration18.3.1. Registry Contents19. References19.1. Normative References19.2. Informative ReferencesAppendix A. Authorization ExamplesA.1. Example using response_type=codeA.2. Example using response_type=id_tokenA.3. Example using response_type=id_token tokenA.4. Example using response_type=code id_tokenA.5. Example using response_type=code tokenA.6. Example using response_type=code id_token tokenA.7. RSA Key Used in ExamplesAppendix B. AcknowledgementsAppendix C. Notices§ Authors' Addresses

▲ 101 블록체인(101 Blockchains) 홈페이지미국 뉴욕을 기반으로 하는 101 블록체인(101 Blockchains)에 따르면 블록체인 및 웹3 인증 프로그램을 위한 CPD(Continuing Professional Development) 공인 인증 제공업체로 자리매김했다.101 블록체인은 실용적인 블록체인 및 web3 전문 교육, 인증 프로그램을 전문으로 하는 종합 플랫폼이다. 독립적인 블록체인 교육 및 연구 플랫폼이다.엄격한 평가 기준을 준수해 '지속적인 전문 개발(Continuing Professional Development, CPD)' 인증 자격을 획득했다. 야심찬 전문가를 위한 지속적으로 전문성울 개발하도록 촉진하는 설계 인증 프로그램이다. CPD 인증 서비스는 1996년 제정됐으며 다양한 부문에 걸쳐 인증을 제공하고 있다. 또한 101 블록체인과 같은 훈련과정 제공업체에 대해 보상 인증을 담당한다.참고로 101 블록체인은 전 세계 전문가들이 블록체인 기술에 대한 최신 정보를 얻을 수 있도록 교육 과정과 인증을 제공하고 있다. 블록체인 기술 및 사용 사례에 관심을 가진 학습자를 위한 지원 리소스를 제공한다.

▲ 나이지리아 쉘트 글로벌(SHELT Global Limited) 홈페이지나이지리아 쉘트 글로벌(SHELT Global Limited)에 따르면 사이버 이뮨(Cyber Immune Limited) 하에 국내외적으로 ISO/IEC 27001:2022 인증을 획득했다.인증기관으로부터 데이터 보안과 관련된 위험을 관리하는 모범 사례를 보유하고 있다. 파트너와 고객을 위해 모범 사례를 적용하고 있음을 인증받았다.쉘트 글로벌은 기술적으로 진보된 유럽 기반 관리형 보안서비스 제공업체(Managed Security Service provider, MSSP)다. 유럽, 중동, 아프리카 주요 기관에 다양한 사이버 보안 서비스를 판매하고 있다.ISO/IEC 27001:2022는 정보보안경영시스템(information security management systems, ISMS)에 대한 세상에서 가장 알려진 최고 표준이다.ISMS가 정보보안 관리시스템을 구축, 구현, 유지 및 지속적으로 개선하기 위해 충족해야 하는 요구사항을 정의하고 있다. ISO/IEC 27001:2022의 접근 방식은 사람, 정책 및 기술을 조사한다.또한 인증된 기업이 위험관리, 사이버 탄력성, 운영 우수성을 구현하고 있는지 감사한다. 파트너 및 고객들이 끊임없이 진화하는 사이버 범죄 환경으로 매일 새로운 위협에 직면해 있기 때문이다. 

▲ 유럽 증권시장국(European Securities and Markets Authority, ESMA) 홈페이지유럽 주식시장을 감독하는 유럽 증권시장국(European Securities and Markets Authority, ESMA)은 유럽위원회(European Commission, EU)로 부터 새로운 권한을 부여받았다고 밝혔다.ESG 등급 제공업체가 규칙 위반을 하지 못하도록 강제할 수 있는 새로운 법률이다. 또한 조사를 준수하거나 현장 검사를 수행하도록 강제할 수 있다.특히 등급 제공자의 연간 총순매출액의 최대 10%에 해당하는 벌금을 부과할 수 있다. 또한 최대 6개월 동안 정기 벌금을 내도록 요구할 수 있다.정기 벌금액은 패널티가 부과되기 전 1년 동안 등급 평가기관이 작성한 1일 평균 매출액의 3%에 해당된다. 비즈니스 활동을 수행 중인 개인(natural persons)의 경우 전년도 평균 1일 소득의 2%를 부과한다.ESG 등급 제공업체는 ESMA에서 발생하는 모든 관리비를 충당하는 수수료를 지불해야 된다. 새로운 기능을 수행하기 위한 총연간비용은 약 370만~380만 유로가 될 것으로 예상된다.ESMA는 공급업체가 규칙을 위반하거나 9개월 동안 사업을 수행하지 않는 경우 ESG 등급 승인을 회수하거나 정지할 수 있다. 법안 초안은 ESG 등급 제공자가 비즈니스와 활동을 분리해 잠재적인 이해 충돌을 공개하도록 요구한다.ESMA는 ESG 등급 제공자에게 ESG 등급의 이해관계자와 사용자를 대표하는 독립 감독기관을 설립하거나 평가 제공자에게 이해 상충을 유발하는 활동을 중단하도록 요청할 수 있다. 또한 ESG 등급 제공을 중단하는 등 위험을 완화하기 위한 조치를 취하도록 요구할 수 있다. ESG 등급 제공자는 투자자나 기업에 대한 컨설팅 활동, 감사 활동, 은행, 보험 또는 재보험 활동, 신용 등급 판매, 벤치마크 개발을 자제해야 된다.유럽위원회(European Commission, EU) 제안한 새로운 법률 세트는 ESG 등급 제공업체가 강제로 엄격한 요구사항을 준수하도록 하기 위함이다.때로는 불투명한 것으로 인식되거나 적절한 투자 의사 결정 프로세스를 방해하는 비즈니스의 투명성과 거버넌스를 개선하기 위한 노력의 일환이다.새로운 입법 제안은 지속가능 금융에 관한 일련의 조치의 구성요소다. 공식적으로 공개된 유럽연합에서 운영되는 공급자가 발행 또는 직장 연금 기관을 포함한 규제 된 금융 회사에 배포된 등급에 적용된다.

▲ 아랍에미리트(UAE) 보건부(Ministry of Health and Prevention, MoHAP) [출처=홈페이지]아랍에미리트(UAE) 보건부(Ministry of Health and Prevention, MoHAP)에 따르면 2023년말까지 스마트 디지털 의료 규제 프레임워크(Smart Digital Health regulatory framework)를 도입하기로 결정했다.지난 3월 보건부 산하 디지털의료부(Digital Health Department) 전략투자실(Strategy and Investment Section)은 두바이에서 개최된 원격포럼에서 도입 계획을 발표했다.UAE에서 도입되는 새로운 규제 프레임워크는 모든 의료 제공업자들이 환자를 위해 최소 하나의 원격 서비스 형태를 제공해야 될 의무를 부담하도록 했다.의료제공업자들은 컨설팅, 약물 처방, 환자 모니터링 또는 로봇 수술과 같은 이러한 서비스 중 적어도 하나를 원격으로 제공해야 된다. 새로운 규제는 공공 및 민간 영역의 의료 서비스 제공업자 모두에게 해당된다.의료 시설은 현재 운영하고 있는 가상 또는 원격 의료 서비스에 대해 보건부에 보고해야 된다. 만약 의료시설이 어떤 것도 보유하고 있지 않다면 올해 연말까지 원격 서비스 중 하나를 갖추도록 협력해 나갈 계획이다.모든 원격 의료 서비스를 규제하고 있는 포괄적인 의료 규제 프레임워크는 의료 시설 및 환자 권리에 대한 역할과 책임을 정의하고 있다.의료 분야의 기술 발전이 급속도로 발전함에 따라 의료 시설에서 원격 서비스를 촉진하는 것이 시급하기 때문이다.정부는 의료 관광으로 진화해 나가고 있는 상황에서 원격 의료 진료와 같은 기본 서비스가 필요하다고 판단했다. 또한 의료 부문 디지털화를 나아가기 위해서도 원격 의료 서비스 도입이 절실한 실정이다.보건부는 의료 진단 및 처방, 원격진료에 대한 의료적 책임이 필요하다고 보고 있으며 이를 위해 명확한 규정을 마련했다. 규칙과 규정을 통해 의료 서비스 제공자에게 경계를 명확히 설정할 수 있을 것으로 전망된다.

▲스리랑카보험공사(Sri Lanka Insurance Corporation, SLIC) [출처=홈페이지]스리랑카 보험공사(Sri Lanka Insurance Corporation, SLIC)는 최근 모바일 장치 기반 디지털 서명 솔루션 출시를 위해 랑카페이(LankaPay)와 계약을 체결했다고 밝혔다.SLIC는 최근 몇 년 동안 운영을 빠르게 디지털화하면서 내부 효율성을 높이는 동시에 고객에게 원할하고 신속한 솔루션을 제공하기 위해 디지털 혁신 전략을 가속화하고 있다.SLIC는 디지털화 여정에서 매우 중요한 단계로 모바일 장치 기반 디지털 서명 솔루션을 구현한 국내 최초의 기관으로 문서 서명 및 승인을 추진했다.SLIC는 내부 및 외부 문서 서명을 위해 모바일 장치에서 랑카사인(LankaSign) 디지털 서명을 추진했다. 랑카사인은 스리랑카에서 디지털 인증서를 발급하는 유일한 인증서비스 공급업자(Certification Service Provider, CSP)다.랑카페이가 운영하고 있는 CSP는 스리랑카 중앙은행(Central Bank of Sri Lanka)과 스리랑카 컴퓨터비상대응팀(Computer Emergency Readiness Team, CERT)의 합의에 의해 설립됐다.또한 랑카사인(LankaSign) 디지털 서명은 스리랑카 정보통신기술청(Information and Communication Technology Agency, ICTA)으로부터 법적으로 인정 받았다. 랑카사인 인증 프로세스는 ISO 27001:2013과 같은 국제 표준을 준수하고 있다. 

미국 클라우드 서비스 업체인 이펙츄얼(Effectual)는 최근 품질 관리 국제 표준 ISO 9001:2015 인증을 획득했다고 밝혔다. 이펙츄얼의 공공부문(Effectual Public Sector Inc.)은 연방(Federal), 주(State), 지방(Local), 교육 및 비영리 조직에 IT 현대화 솔류션을 제공한다. ISO 9001:2015는 국제 표준화 기구(ISO)에서 발행된 세계적으로 인정받는 품질 관리 표준이다. 특히 기업이 글로벌 비즈니스 전략에 부합하는 품질 관리 시스템을 개발하도록 안내한다. ISO 9001 표준은 커뮤니케이션, 운영 효율성, 고객 중심 및 직원 참여를 개선하기 위한 모든 조직 프로세스에서 증거 기반 의사 결정 및 책임에 중점을 두고 있다.특히 고객이 고품질 제품과 서비스를 지속적으로 지원 받을수 있도록 조직이 효과적인 품질 관리를 달성하는 데 필요한 구조, 책임 및 절차를 문서화하고 검토하는 프로세스 지향적인 접근 방식을 제공한다.이와 같은 ISO 9001 인증 획득은 디지털 혁신을 위한 파트너로서 고객의 신뢰를 더욱 강화할 수 있을 것으로 분석된다. 최고 수준의 품질 및 규정 준수를 달성하고 유지하기 위한 지속적인 노력의 일부로 평가되기 때문이다.이펙츄얼은 자격 증명, 인증 및 계약 수단을 통해 확장성이 뛰어난 환경을 설계, 구축, 보호 및 관리할 수 있는 입증된 능력을 보유하고 있다. 이를 통해 혁신적인 클라우드 솔루션을 성공적으로 제공하고 새로운 도구를 구현하고 있다.참고로 이펙츄럴은 AWS MSP(Managed Services Provider) 지정, AWS 마이그레이션 컨설팅 컴피턴시(Migration Consulting Competency), AWS DevOps 컨설팅 컴피턴시(Consulting Competency), AWS 모바일 컨설팅 컴피턴시, AWS SaaS 컨설팅 컴피턴시, AWS 정부 컨설팅 컴피턴시 및 AWS 비영리 컨설팅 컴피턴시 지정을 획득했다.또한 AWS Well-Architected 파트너 프로그램, AWS 공공 부문 파트너 프로그램(Public Sector Partner Programs), AWS GovCloud(미국) 및 AWS 프로그램 운영 권한의 회원이며 CSA(Cloud Security Alliance) 및 PCI SSC(Security Standards Council) 회원이다.▲ 이펙츄얼(Effectual)의 홍보자료(출처 : 홈페이지)

영국 선도적인 미생물 테스트 회사 MSL(MSL Solution Providers)에 따르면 2022년 7월 15일 UKAS 4045로부터 살생물제 서비스에 대한 최신 ISO/IEC 17025:2017 인증을 획득했다.UKAS의 평가에 따라 2022년 6월 30일 승인됐으며 UKAS 4045인증을 받은 화장품 테스트 서비스 업체로 부상했다. MSL은 사내 실험실과 모든 모든 필수 시험들이 업데이트된 ISO/IEC 17025 표준을 준수하고 있음을 보장받게 됐다.또한 MSL은 UKAS에 의해 ISO/IEC 17025:2017 표준을 인증받은 소수의 독립 연구소 중 하나다. 이는 가능한 최고의 품질 테스트 서비스를 제공하겠다는 MSL의 의지를 반영하고 있다.ISO/IEC 17025:2017 표준은 테스트 연구소의 역량에 대한 일반적인 요구사항을 명시하고 있다. 이전에는 실험실만 인증의 대상이었으나 개정된 표준은 해당시험이 수행되는 실험실뿐 아니라 필수 시험 자체를 포함한다.최근 MSL은 환경 지속 가능성과 관련한 ISO 14001 인증과 최고 수준의 정보 보안 관리를 준수하고 있음을 확인해 주는 ISO 27001 인증을 추가로 획득했다.▲MSL Solution Providers 홈페이지

국제표준화기구(International Organization for Standardization, ISO)에 따르면 국제전기기술위원회(International Electrotechnical Commission, IEC)와 함께 개발한 ISO/IEC 27017 표준이 클라우드 보안 사고를 해결할 수 있다.ISO/IEC 27017 표준은 정보보안 통제 구현에서 클라우드 서비스 고객, 클라우드 서비스 제공자(cloud service providers, CSPs)를 지원하는 지침을 제공한다.지침 중 일부는 클라우드 서비스 고객과 관련이 있으며 일부는 CSP와 연관돼 있다. 지침의 적용은 위험 평가 결과와 보안 요구사항의 특성에 따라 다르다.ISO 27017은 자산관리, 반환, 접근 통제, 물리적 보안, 준수 등을 포함해 주요 제어 영역에 초점을 맞춰 ISO/IEC 27001/270702 지침을 보완하고 있다. 국제표준은 다음과 같이 7가지 새로운 규제를 제시하고 있다.6.3.1 클라우드 컴퓨팅 환경 내에서 역할 및 책임공유8.1.5 클라우드 서비스 고객 자산 제거9.5.1 가상 컴퓨팅 환경에서의 분리9.5.2 가상 시스템 강화12.1.5 관리자의 운영 보안12.4.5 클라우드 서비스 모니터링13.1.4 가상 및 물리적 네트워크에 대한 보안 관리 조정ISO/IEC 27017 표준은 조직과 보안 전문가들이 고민하고 있는 문제를 해결하는데 도움이 된다. 미국 IT기업 뉴스 제공업체 베타뉴스(BetaNews)의 설문조사 결과에 따르면 "응답자의 36%가 지난 12개월 동안 심각한 클라우드 보안 데이터 유출 및 침해 사고에 시달리고 있다."고 밝혔다.클라우드 전문가 300명을 대상으로 실시한 설문조사에서 참가자 10명 중 8명이 클라우드 구성 오류와 관련한 데이터 유출에 취약할 것이라고 우려했다. 응답자의 64%는 1년 후에도 문제가 그대로 유지되거나 악화될 것이라고 답변했다.클라우드 전문가 20%는 피로 경고, 잘못된 긍정, 인적 오류 등이 클라우드 보안 노력을 방해하고 있다고 봤다. 또한 "36% 이상은 클라우드 보안 전문가를 고용하고 보유하는데 어려움이 있다"고 밝혔다.나머지 36% 가까운 응답자는 "클라우드팀에 보안 교육을 시키는데 어려움을 겪고 있어 클라우드 보안 유출 및 침해 사고 예방을 위해 전략적 접근 방식이 필요하다"고 지적했다.▲ 국제표준화기구(ISO) 홈페이지