不適切なコーディングパターンは大きなセキュリティ問題につながる可能性があります... では、なぜ私たちはそれらを奨励するのでしょうか？

이 기사의 버전이 게재된 곳 DZone. 여기에서 업데이트 및 신디케이트되었습니다.

‍

이 시점에서 영원같은 느낌에 대해 소프트웨어 개발 초기부터 보안 모범 사례를 고려하여 SDLC에서 "왼쪽으로 이동"에 대해 논의했습니다. DevSecOps는 보안에 대한 공동 책임과 코드를 작성할 때 일반적인 취약점을 저지하기 위한 보안 인식 개발자의 힘 때문에 작은 부분에서 큰 도약이었습니다. 

또한 개발자의 참여와 기술 향상을 위해 어떤 유형의 보안 코드 교육을 선택하느냐가 모든 차이를 만든다는 사실을 우리는 오랫동안 알고 있었습니다. 규정 준수에만 초점을 맞춘 저비용 솔루션으로는 미래의 밝은 보안 마인드를 키울 수 없으며, 대부분의 보안 인식 전문가들도 이를 잘 알고 있습니다. 상황에 맞는 역동적인 학습이 가장 좋지만, 그 안의 뉘앙스를 이해하는 것이 중요합니다. 

조직에서 항상 우위를 점하고 있는 위협 행위자들과 맞서 싸우려면 개발자에게 모범 사례에 기반한 기술을 지속적으로 쌓을 수 있는 계층화된 학습이 포함된 종합적인 교육 환경이 필요합니다.

개발자가 주도하는 방어적 보안 조치가 자동적으로 승리하는 것은 아닙니다.

저희의 정신은 개발자가 예방적 보안 전략의 중심이 되어야 하며, 바로 코드 수준에서 시작해야 한다는 것입니다. 이는 당연한 일이며, 보안에 숙련된 개발자는 잘못된 코딩 패턴에서 드러나는 일반적인 보안 버그 유형(최근의 치명적인 예로 Log4Shell과 같은)을 가장 쉽게 차단할 수 있는 방법을 제공합니다.

그러나 개발자를 숙련시키기 위해 사용할 수 있는 방어 기법은 동일한 교육 버킷에 포함될 수 있더라도 다양합니다. 

예를 들어, 하지 말아야 할 것들에 대한 지침만 사용하여 케이크를 굽는 방법을 설명받았다고 상상해 보세요. "너무 많이 굽지 마세요", "달걀을 잊지 마세요"와 같은 지침은 해석의 여지를 남기며 실수할 가능성이 매우 높습니다. 성공!. 방어적 보안 교육도 마찬가지입니다. 하지 말아야 할 것은 대화의 매우 제한된 부분이며, 진정한 방어적 사고방식으로 행동하기 위한 실질적인 조언은 제공하지 않습니다. 개발자에게 "API를 잘못 구성하지 마세요"라고 말할 수는 있지만, 무엇이 올바르고 안전한 구성을 구성하는지에 대한 이해가 없다면 오류가 발생할 여지가 많습니다.

개발자는 취약점이 어떻게 작동하는지, 왜 위험한지, 어떤 패턴이 취약점을 유발하는지, 어떤 설계 또는 코딩 패턴이 자신의 세계에서 의미 있는 맥락에서 취약점을 수정하는지에 대한 기본적인 이해가 없으면 취약점 감소에 긍정적인 영향을 미치지 못할 것입니다. 스캐폴드 접근 방식을 사용하면 여러 지식 계층을 통해 안전하게 코딩하고, 코드베이스를 방어하고, 보안을 인식하는 개발자로 우뚝 서는 것이 무엇을 의미하는지에 대한 전체적인 그림을 그릴 수 있습니다. 물론 이러한 계층적 학습의 일부는 공격과 공격자의 사고방식을 이해하는 데 사용되어야 하며, 이는 위협 모델링과 방어 전략에 매우 중요한 측면적 사고 기술을 연마하는 데 매우 중요합니다. 

잘못된 코딩 패턴을 강화하는 것은 무시할 수 없는 함정입니다.

일부 개발자 학습 방법의 안타까운 현실은 공격적인 기법으로 교육을 구성하더라도 '방어적인' 부분이 기술적으로 코드 보안을 검증하는 경우에도 나쁜 습관을 강화할 수 있다는 것입니다. 

고품질 코드의 생산은 모든 소프트웨어 개발의 기본이 되어야 하지만, '품질'의 정의에 대해서는 여전히 논쟁의 여지가 있습니다. 안전하지 않은 코드는 아무리 기능적이고 아름답더라도 고품질 코드라고 볼 수 없다는 것이 현실입니다. 더 중요한 것은 보안 코드가 본질적으로 높은 품질을 가지고 있지도 않다는 것입니다. 즉, 잘못된 코딩 패턴은 보안 문제를 해결할 수는 있지만, 그 과정에서 또 다른 문제를 야기하거나 소프트웨어를 완전히 망가뜨릴 수도 있습니다. 

깨진 인증에 대한 수정 사항과 모범 사례를 위한 가장 안전한 버전으로 품질이 좋지 않은 코드의 예를 살펴보겠습니다:

‍

System;

System.Collections.Generic을 사용합니다;

System.Linq를 사용합니다;

System.Threading.Tasks를 사용합니다;

Microsoft.AspNetCore.Authorization을 사용합니다;

Microsoft.AspNetCore.Http;

Microsoft.AspNetCore.Mvc를 사용합니다;

‍

네임스페이스 BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    공용 클래스 AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")]

        // Does not ensure that the user is authenticated 

        public IEnumerable<Alert> Get()

        {

            context.GetAlerts()를 반환합니다;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, but does not check any roles

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            context.GetAlerts()를 반환합니다;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, AND that they have the "Administrator" role

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            context.GetAlerts()를 반환합니다;

        }

    }

}

‍

첫 번째 스니펫에서는 사용자가 인증되었는지 확인하는 검사가 없으므로 안전하지 않습니다. 두 번째는 인증 검사를 수행한다는 측면에서 더 낫지만 할당된 역할과 요청된 정보에 대한 권한이 충분히 높은지 여부를 조사하지 않습니다. 세 번째는 사용자 인증과 '관리자' 역할이 할당되었는지 모두 확인합니다. 대부분의 경우 최소 권한 액세스 제어가 표준이 되어야 하는 시대에는 꼭 알아야 할 경우에만 정보에 액세스할 수 있도록 역할을 설정하고 확인하는 것이 중요합니다. 

개발자의 최우선 순위는 기능을 개발하는 것이며, 보안을 의도적으로 뒷전으로 미루는 것은 아니지만, 보안 버그를 유발하는 잘못된 코딩 패턴을 피할 수 있는 기술이 반드시 있는 것은 아니며, 훌륭한 엔지니어의 기준에는 보안 코딩 능력이 포함되지 않는 경우가 많습니다. 기능이 충분히 훌륭하다면 이러한 나쁜 습관을 간접적으로 장려하는 셈인데, 이러한 사고방식을 바꿔야 합니다. 문제는 일부 학습 경로에서 실습을 통한 코드 수정을 장려하는 방식이 안전하지만 품질이 떨어지는 코드를 강화할 가능성이 있다는 점입니다. "예, 이것은 안전합니다/아니요, 이것은 안전하지 않습니다"라는 이분법( assessment)을 적용하면 버그를 해결하고 소프트웨어의 무결성을 유지하는 데 진정으로 최선의 접근 방식인지 더 깊이 들여다보지 않고 세부 사항에서 눈에 띄지 않는 악마가 존재합니다. 

이러한 접근 방식은 개발자가 전체 프로세스를 통해 보안 코딩에 대한 전체적인 관점을 갖도록 하지 않기 때문에 해결하고자 하는 동일한 문제를 지속시킵니다. 우리 모두가 목적지까지 차량을 운전할 수 있는 능력만을 기준으로 면허를 취득하고, 빨간불을 위반하고 울타리를 통과하고 길을 건너는 보행자를 간신히 놓쳤음에도 불구하고 합격점을 받았다고 상상해 보세요. 우리는 목표를 완수했지만 그곳에 도착하기까지의 여정이 가장 중요합니다. 

개발자가 안전한 소프트웨어를 만드는 데 더 많은 관심을 가질 수 있도록 지원해야 합니다.

현대의 개발자는 많은 일을 처리해야 하므로 보안 교육이 지루하다고 느끼는 것은 당연한 일이며, 특히 업무 일정을 염두에 두고 시행되지 않고 마감일과 우선순위에서 멀어지게 하는 경우 더욱 그렇습니다. 또한 정기적이고 적절한 학습 기회와 보조 도구를 통해 기술을 쌓지 않은 상태에서 보안 코딩에 중점을 두도록 KPI를 변경하는 것은 완전히 불공평합니다. 그러나 안전한 소프트웨어 개발의 중요성은 아무리 강조해도 지나치지 않으며, 개발자가 이에 동참하도록 하는 것이 중요합니다. 

전직 개발자로서, 일반적으로 우리는 훌륭한 일을 하고 싶어하며 , 품질 결과물 측면에서 다른 사람들보다 우월한 것으로 간주되는 것은 매우 동기 부여가 됩니다. 개발자가 지속적인 보안 기술 개발에 참여하도록 인센티브를 제공하는 것은 당연한 일이며, 코드 수준 보안의 중요성을 인식한 개발자에게는 보상을 제공해야 합니다. 보안 챔피언 프로그램, 버그 바운티, 해커톤은 긍정적인 보안 문화를 구축할 수 있는 좋은 기회가 될 수 있으며, 적극적으로 참여하는 개발자는 전리품을 얻을 수 있어야 합니다.