2025 년까지 총 글로벌 데이터 생성 181제타바이트에 도달합니다. 기업의 경우 해당 데이터는 자산이므로 다양한 기술 플랫폼을 활용하여 충성도를 높이고 새로운 비즈니스를 유치하는 고도로 개인화된 고객 경험을 만들 수 있습니다. 그러나 이러한 경험은 공유 보안 모드를 사용하는 클라우드 인프라에 따라 달라집니다. 바로 여기에 위험이 있으며 기술이 성장함에 따라 로우 코드 및 노코드 플랫폼을 사용하는 새로운 시민 개발자 군대를 통합하는 위험이 증가하고 있습니다.
상속 사고방식의 이해와 극복
가트너 2025년까지 엔터프라이즈 애플리케이션의 70%가 Salesforce 및 ServiceNow와 같은 로우 코드 및 노 코드 플랫폼에서 구축될 것으로 추정됩니다. 상속 기반 사고방식으로 대응하는 것은 기업용 앱의 XNUMX/XNUMX 이상을 실패하게 만드는 확실한 방법입니다.
"상속 사고방식"은 인프라를 괴롭히는 문제에 대한 적절한 설명입니다. 그것은 수행된 일과 그들보다 먼저 온 사람들에게 전적으로 의존하는 부유하고 버릇없는 아이들을 생각나게 합니다. 그것은 유산을 구축하는 좋은 방법이 아니며 시스템을 구축하는 데에도 똑같이 나쁜 방법입니다.
레거시 사고방식을 갖고 있으면 인프라가 설정되어 있다고 가정합니다. 플랫폼은 안전하고 보안이 내장되어 있습니다. 관리자보다 먼저 기술이 있었기 때문에 신뢰가 가정됩니다.
이러한 상속 사고방식은 로우코드 및 노코드 플랫폼을 괴롭힙니다. 사용자는 전체 기업 인프라를 통해 이를 수행하기 위해 플랫폼의 안전성에 의존합니다. 대신 해당 플랫폼의 보안은 해당 플랫폼에만 적용되어야 합니다.
Salesforce 개발자가 새로운 리드에 대한 자동 할당 프로그램을 만든다고 가정해 보겠습니다. 내부 과제를 위해 Salesforce 내에서 사용하는데 괜찮습니다. 그들은 플랫폼의 안전성에 의존할 수 있습니다. 그들은 자동화를 개선하기 위해 이를 확장하기로 결정했습니다. 해당 프로그램을 ServiceNow, SAP 또는 Oracle과 같은 외부 CRM에 연결합니다. 상속 사고방식이 이어집니다. Salesforce는 안전합니다. ServiceNow, SAP 또는 타사는 안전합니다.
따라서 Salesforce + 타사 = 안전합니다.
하지만 그 더하기 기호에는 알려지지 않은 내용이 많이 있습니다. Salesforce에서 생성된 내부 프로그램을 타사 플랫폼에서 생성된 외부 프로그램에 어떻게 안전하고 규정에 맞게 연결합니까? 그 단일 문자에는 오류의 여지가 많습니다.
그리고 그것은 단 하나의 연결일 뿐입니다. Salesforce에서 생성된 많은 프로그램은 수백 가지 다른 프로그램과 관련이 있습니다. 개발 경험이 거의 또는 전혀 없는 사람들이 위에서 설명한 더하기 기호처럼 취급되는 수백 개의 알려지지 않은 항목입니다.
유일한 해결책은 DevSecOps 원칙으로 돌아가서 해당 개발을 다시 현실화하는 것입니다.
DevSecOps 프레임워크 설정
DevSecOps 프레임워크는 개념이 만들어진 이후 작성되고, 다시 작성되고, 다시 작성되었습니다. 특히, 이를 확립할 때 바퀴를 재발명할 필요가 없습니다. SAFECode 및 클라우드 보안 연합 여섯 개의 기둥을 세웠습니다.
- 집단적 책임: 보안은 기업 내 모든 사람의 책임입니다. 그러나 사람들은 자신이 모르는 표준을 충족할 수 없습니다. 사이버 보안 정책을 추진하고 해당 정책이 기업 전체에 전파되도록 리드를 할당해야 합니다.
- 협업 및 통합: 지식은 공유되고 전달되어야 합니다. 기업이 레거시 사고방식에 빠지는 이유 중 절반은 기존 시스템을 아는 모든 사람이 사라졌기 때문입니다. 지속적인 지식 공유는 이 문제를 해결하는 데 도움이 됩니다.
- 실용적인 구현: 실용적인 구현은 개발자 경험과 연결됩니다. 어렵고 평범하며 다루기 힘든 프로세스는 오랫동안 따르지 않습니다. 보안은 개발 관행에 반영되어야 합니다. 즉, 모든 코드 줄에는 테스트 줄이 필요합니다. 높은 성과를 내는 기업은 테스트 코드의 각 줄을 자동화하는 도구를 사용하여 이를 더욱 발전시킬 것입니다.
- 규정 준수 및 개발: 규정 준수 요구 사항은 개발자가 규정에서 벗어나는 것을 허용하지 않는 방식으로 개발 프로세스를 안내해야 합니다. 예를 들어 금융 기관의 개발자는 Gramm-Leach-Bliley Act를 준수하도록 설계된 플랫폼에서 작업합니다. 개발자는 플랫폼에 내장되어 있기 때문에 규정을 준수하기 위해 개별적인 세부 사항을 알 필요가 없습니다.
- 자동화 : 예측 가능하고 반복 가능하며 볼륨이 높은 작업은 가능할 때마다 자동화하여 개발자의 부담을 줄이고 인적 오류의 위험을 줄여야 합니다.
- 모니터 : 최신 클라우드 인프라는 변화하고 성장합니다. 이상적으로는 모든 다양한 상호 연결을 한 눈에 볼 수 있는 일종의 오케스트레이션을 통해 추적하는 것이 중요합니다.
안에 코드가 적거나 없음 환경에서 이러한 기둥은 예상만큼 간단하지 않습니다. 이러한 도구를 사용하는 사람들은 DevSecOps 기본 사항에 거의 익숙하지 않은 비즈니스 전문가인 경우가 많습니다.
사람, 프로세스, 기술의 결합
로우코드 및 노코드 플랫폼을 사용하면 실제로 이러한 기술 격차를 줄이는 데 도움이 될 수 있습니다. 직원들은 새로운 기술을 배우고 싶어합니다. 기업은 사람, 프로세스 및 기술에 초점을 맞춘 DevSecOps 프레임워크를 구축하여 이를 지원할 수 있습니다.
- 프로세스 : 제로 트러스트 환경에서 로우 코드 및 노 코드 개발자는 시스템 무결성을 위협하는 연결을 수행할 수 없기 때문에 걱정할 필요가 없습니다. 격리된 시스템 외부에는 기본 권한이 없습니다.
- 사람 : 책임의 문화는 비난의 문화와 다릅니다. 책임은 사람이 아니라 문제에 초점이 맞춰져 있기 때문에 개인이 문제나 실수를 제기하는 것을 편안하게 느끼는 것을 의미합니다.
- 기술: 기술은 개발자의 손에 있지 않기 때문에 DevSecOps 원칙을 적절하게 구현하는 데 가장 큰 장벽입니다. 그들은 조직에서 제공하는 것을 사용해야 합니다. 해당 기술이 작동하지 않으면 개발자는 안전하지도 안전하지도 않은 해결 방법을 찾아낼 것입니다. 본질적으로 기술은 하나의 거대한 섀도우 IT 생성기가 됩니다.
우리는 발전을 위한 흥미로운 시대에 살고 있습니다. 점점 더 많은 사람들이 소프트웨어를 구축하고, 전략을 테스트하고, 비즈니스 가치를 향상시킬 수 있는 기회를 갖게 되었습니다. 하지만 그러기 위해서는 위험이 따른다. 이러한 위험을 기술에 맡기는 방법을 모색하는 기업은 탐색할 여지를 남겨두면서 개발을 현실적으로 유지할 것입니다.
