2023년에도 최고의 보안을 유지하는 방법

보안 및 성능은 개발하는 모든 프로젝트, 사이트, 앱 및 구성 요소의 초석입니다. 그러나 이렇게 끊임없이 변화하는 환경에서 근본적인 모범 사례를 유지하면서 동시에 혁신하는 것은 어려울 수 있습니다.

이 대화에서 2023년 최고의 보안 및 성능을 유지하는 방법에 대해 최고의 기술자로부터 들어보십시오.

스피커:

• WP Engine의 SVP 겸 최고 기술 책임자인 Ramadass Prabhakar
• Lawrence Edmondson, Barbarian의 CTO
• Sergi Isasi, 제품 부사장, Cloudflare의 애플리케이션 성능
• Tim Nash, timnash.co.uk의 WordPress 보안 컨설턴트
• space150의 CTO 지미 스콰이어

성적 증명서:

RAMADASS: 안녕하세요, 여러분. Decode의 네 번째 버전에 오신 것을 환영합니다. 매년 참석자들의 성장을 보는 것은 놀라운 일이었습니다. 지난 몇 년 동안 업계 전반에 걸쳐 보안 환경에 상당한 변화가 있었습니다. 고객 및 개발자와의 토론에서 주제가 자주 나오므로 보안 위반 및 보안에 대한 정기적인 뉴스 게시판을 보았습니다. 그래서 오늘 우리는 보안에 대한 열정을 갖고 우리의 질문에 답하고 배운 내용을 공유하기 위해 여기에 모인 멋진 업계 전문가 그룹을 모았습니다. 패널리스트에 대한 간략한 소개부터 시작하겠습니다. 로렌스, 당신에게.

LAWRENCE EDMONDSON: 초대해 주셔서 감사합니다. Barbarian의 CTO인 Lawrence Edmondson입니다. Barbarian은 풀 서비스 디지털 에이전시입니다. 우리는 뉴욕에 있습니다.

RAMADASS: 고마워요, 로렌스. 당신에게, 세르지.

세르지 이사시: 감사합니다. 저는 Cloudflare의 제품 부사장입니다. Cloudflare, 우리는 WPE와 같은 고객 및 파트너가 인터넷에 더 안전하고 빠르게 연결할 수 있도록 하는 제품을 만듭니다. 저는 샌프란시스코에 있습니다.

진행자: 감사합니다, Sergi. 그리고 팀, 당신에게.

TIM NASH: 저는 영국에서 WordPress 보안 컨설턴트로 일하고 있습니다. 그리고 나는 기본적으로 내 인생을 개발자를 겁주는 데 보냅니다.

진행자: 감사합니다. 그리고 지미.

JIMMY SQUIRES: 네, 감사합니다. 저는 미니애폴리스의 풀 서비스 디지털 에이전시이자 그곳의 CTO인 Space 150에서 근무하고 있습니다.

진행자: 오늘 패널로 참여해 주셔서 감사합니다. 오늘 조직 내에서 또는 팀 내에서 보안과 관련하여 수행하고 있는 고유한 작업에 대해 이야기하면서 시작하겠습니다. Sergi부터 시작하겠습니다.

SERGI ISASI: 네, Tim의 인트로에서 그가 개발자를 겁주는 부분을 재생하겠습니다. Cloudflare에서 더 많은 노력을 기울이고 있는 것 중 하나는 고객에게 트래픽에 대한 더 많은 통찰력을 제공하고 운영 부담을 줄이는 것입니다. 따라서 역사적으로 네트워크에 영향을 줄 수 있는 것이 무엇인지, 공격이 무엇인지 확인하려면 WAF를 배포하고 로그 모드에 넣은 다음 보안 분석가가 로그를 살펴보고 그것이 무엇을 감지했는지보십시오. 그리고 요즘에는 그렇게 할 수 있는 리소스가 훨씬 적습니다.

따라서 올해 우리의 초점은 고객이 현재 해당 공격을 방지할 수 있는 제품을 사용하지 않더라도 우리가 본 공격에 대한 통찰력을 고객에게 제공하는 것입니다. 따라서 애플리케이션이 공격을 받고 있는지 또는 일반적으로 양호한 상태인지 알 수 있습니다. 그리고 올해 남은 기간 동안 우리의 모든 보안 제품을 소개하고 고객에게 무슨 일이 일어나고 있는지, 네트워크에서 실제로 어떤 일이 일어나고 있는지, 그리고 그것을 차단할지 여부를 알리는 것이 우리의 초점입니다.

진행자: 훌륭합니다. 실제로 정말 강력하게 들립니다. 나는 그것에 대해 더 많이 듣기를 고대하고 있습니다. 그래서 팀, 너 자신은 어때?

TIM NASH: 그래서 저는 대행사뿐 아니라 소규모 개별 웹사이트까지 다양한 고객과 함께 일합니다. 그리고 저는 코드 리뷰와 사이트 리뷰를 많이 합니다. 그리고 올해까지는 사람들이 리뷰를 받고 당신이 하라고 한 일을 하는 것을 매우 기뻐할 정도로 실제로 관심을 갖는 사람들의 성장을 보지 못했습니다. 그래서 당신이 그들에게 많은 추천을 주면 그들은 그냥 따라합니다. 하지만 내년에 사이트를 다시 방문하면 또 다른 권장 사항을 제공하는 것입니다. 그래서 저는 작년에 사람들이 실제로 질문을 할 만큼 충분히 관심을 갖는 변화를 많이 보았습니다. 그래서 저에게는 이 파일의 크고 긴 6, 4, 2행에서 코드 감사가 버려졌습니다. 어쩌구 저쩌구 이렇게 해야 합니다.

나는 그 모든 것을 없애고 교육에 집중하기 시작했고 솔직히 말해서 대부분의 사람들이 원하는 것은 말하는 것이 아니라 이 줄을 고쳐야 한다는 것을 깨달았습니다. 거기에 있는 모든 줄. 그래서 저에게 큰 변화와 큰 초점 변화는 교육에 대한 것이었습니다. 그리고 이것은 산업 전반에 걸친 것입니다. 올해는 작년보다 보안에 대해 이야기하는 사람들이 점점 더 많아지고 있고, 예년보다 더 많이 이야기하고 있다고 생각합니다.

진행자: 아니요, 훌륭합니다. 나는 당신에게 물고기를 주는 것에서 물고기를 잡는 방법을 가르치는 것으로 초점을 옮기는 것을 정말 좋아합니다. 그래서 정말-

TIM NASH: 나는 진부하다는 이유로 그 비유를 피하려고 노력했습니다.

진행자: 감사합니다.

TIM NASH: 잘했어요.

진행자: 좋습니다, 지미.

JIMMY SQUIRES: 네, 너무 많은 것 같아서 이 답변에 대해 이야기할 정말 구체적인 한 가지에 집중하기로 했습니다. 이는 API 토큰 및 액세스를 처리할 때 실제로 범위를 제한합니다. 작년의 Heroku, GitHub 리포지토리 위반은 당신이 너무 많은 것을 제어할 수 있다는 것을 정말 잘 상기시켜준 것 같습니다. 따라서 개발자와 작업할 때 작업 중인 플랫폼이나 시스템에 관계없이 범위 지정 액세스 정책의 중요성을 상기시킵니다. 많은 경우 개발자는 단지 편의를 위해 개발 초기에 상당히 광범위한 공개 액세스를 원합니다. 그리고 때때로 우리가 인정하는 것이 부끄러운 일이지만 생산 전에 있어야 할 수준으로 조여지지 않습니다. 따라서 이러한 보안 범위를 실제로 고려하여 일찍 시작하십시오.

진행자: 감사합니다, 지미. 그리고 Lawrence, 당신이 개발자들과도 많은 일을 한다는 것을 알고 있습니다. 그래서 그 앞에서 무엇을 찾고 있습니까?

로렌스 에드몬드슨: 네, 물론이죠. Jimmy가 말한 것을 기반으로 하여 확실히 우리 둘 다 광고 분야에서 일합니다. 따라서 광고 분야에서 일할 때와 제품 환경에서 일할 때 동일한 문제가 많이 발생한다고 생각합니다. 우리는 다양한 기술, 다양한 기술 스택을 접합니다. 우리는 기술적으로 불가지론자여야 합니다. 그래서 우리가 보고 있는 것은 소비자들이 모바일과 소셜을 통해 다양한 방식으로 참여하고 있다는 것입니다. 몇 년 전에는 데스크톱이 사이트와 콘텐츠에 액세스하는 주요 수단이었습니다. 이제 완전히 뒤집어졌습니다. 데스크톱에서 모바일로, 이제는 소셜로 이동했습니다.

따라서 API 계층과 애플리케이션 계층은 건전한 편집증이 약간 있는 방식으로 잠겨 있어야 합니다. 그래서 우리가 보고 있는 것은 공격 스펙트럼이 증가하고 있기 때문에 우리는 DevOps가 프로그래머처럼 생각하여 가능한 위반 방법을 이해하도록 하는 새로운 방법을 지속적으로 찾고 있습니다. 이것이 오늘날 우리가 하고 있는 일입니다.

진행자: 감사합니다. 그리고 공격 벡터가 어떻게 증가하고 있는지 언급하셨습니다. 이것이 바로 여기 WP Engine에서 심층 방어 메커니즘을 채택하는 방법에서 더 많은 것을 살펴보고 있는 것입니다. 따라서 안전한 계층을 신뢰하지 마십시오. 그리고 그것을 코딩 방식과 소프트웨어 작성 방식에 어떻게 통합합니까? 감사합니다. 그곳에서 일어나고 있는 변화하는 추세에 대해 모두 말씀하셨듯이 작년에 발생한 위반 사항이 있습니다. 2023년을 바라보면서 여러분 모두가 주목하고 있는 주요 주제나 위협은 무엇입니까? 그리고 아마도 Sergi, 당신은 우리를 시작할 수 있습니다. 응.

세르지 이사시: 물론이죠. 그리고 이것은 2023년이고 DDOS라는 단어를 말할 것이기 때문에 이것은 어리석게 들릴 것입니다. 그러나 그것은 여전히 ​​문제입니다. 그리고 DDOS 세계에서 지난 9, 12개월 동안 정말 흥미로운 변화였습니다. Volumetric은 요즘 DDOS 벡터가 아닙니다. 반사가 훨씬 적습니다. 그리고 위협 행위자의 관점에서 볼 때 기성 도구가 많기 때문에 DDOS를 시작하는 것이 더 쉽습니다. 우리는 거의 스크립트 TD 일로 돌아가지만 공격할 수 있는 손상된 시스템도 훨씬 적습니다. 따라서 반영을 시도하는 경우 시스템에 패치를 적용하지 않은 사람이 관리하는 인프라가 많지 않으므로 하나의 패킷을 가져와 10개로 전환할 수 있습니다. 더 이상 중요하지 않습니다.

그래서 그들은 레이어 7로 이동하고 있습니다. 그리고 레이어 7은 시작하는 데 더 많은 CPU가 필요하다는 점에서 더 비싸지만 완화하는 데에도 훨씬 더 비쌉니다. 따라서 일종의 DDOS 보호 시스템이 있는 경우 실제로 연결을 수락하고 검사한 다음 삭제를 시작해야 합니다. 우리가 발견한 것과 우리는 기록상 바로 지난 달에 보고된 최대 규모의 레이어 7 DDOS를 완화했습니다. 이러한 공격의 큰 주제는 더 강력한 장치입니다.

따라서 요즘 우리가 집에 연결한 모든 것을 생각해보면 해당 장치의 프로세서는 3~4년 전보다 훨씬 더 좋아졌습니다. 따라서 카메라는 훨씬 더 많은 일을 합니다. 따라서 더 강력한 CPU가 장착되어 있고 심지어 라우터도 실제로 상당히 강력한 기계입니다. 이러한 장치에 대한 손상은 대규모 공격을 허용할 수 있습니다. 특히 하나를 손상시키면 기본적으로 연결된 모든 장치가 손상되기 때문입니다.

요즘 우리가 조금 더 이야기하지만 좀 더 조용한 또 다른 사항은 손상된 하드웨어 장치에서 클라우드 서비스의 손상된 계정으로 이동했다는 것입니다. 클라우드 서비스에는 CPU가 사실상 무제한입니다. 따라서 여러 개인 또는 회사 계정에 액세스할 수 있고 해당 클라우드 시스템에서 원하는 모든 것을 가동할 수 있다면 매우 큰 공격을 시작할 수 있습니다. 이것이 기록적인 공격에서 우리가 보고 있는 것입니다. 예, 2023년에도 여전히 DDOS는 여전히 중요하지만 이제 하위 계층과 비교하여 계층 7에 있습니다.

진행자: 감사합니다. 무섭기도 하지만 동시에 보안 프로토콜을 계속 강화하고 초점 영역이 계속 성장하는 방법을 가리킨다고 생각합니다. 알아요, 로렌스, 당신과 저는 과거에 AI를 붐이자 위협으로 이야기했습니다. 생성 AI에 대한 귀하의 생각과 그것이 2023년 보안의 표면 영역에 실제로 영향을 미칠 것으로 보는 방법을 듣고 싶습니다.

LAWRENCE EDMONDSON: 그래서 저는 매우 흥분되고 AI에 대해 매우 낙관적입니다. 우리는 Barbarian에 있지만 동시에 매우 무섭습니다. chatGPT와 같은 것이 악의적인 방식으로 사용될 가능성이 있습니다. 예를 들어 Chat GPT가 코드에 주석을 달도록 할 수 있습니다. 그리고 실제로 꽤 괜찮은 작업을 수행합니다. 어떤 언어와 코드가 얼마나 지저분한지에 따라 꽤 잘 작동합니다. 다음으로 볼 수 있는 것은 Chat GPT에 대한 것입니다. Chat GPT가 매일 이 작업을 수행하기 때문에 이미 진행 중일 수 있습니다. 오늘처럼 Slack에서 응답하고 Slack에서 답변을 찾을 수 있는 것을 방금 보았습니다.

보안 측면에서 Chat GPT의 다음 단계는 Chat GPT가 익스플로잇을 찾고 실제로 악성 코드에 코드를 작성하여 발견한 약점을 실제로 악용하는 것입니다. 그래서 우리는 그것을 보고 있습니다. 특히 메모리에 대한 가능성이 있습니다. 따라서 메모리 공격은 항상 서명을 남기지 않습니다. 따라서 기존의 바이러스 및 바이러스 스캐너는 공격의 서명을 찾기 위해 노력합니다. 메모리 공격 내에서 애플리케이션을 공격하고 있습니다. 버퍼 오버플로와 같은 작업을 수행하고 있습니다. 런타임에 애플리케이션을 손상시키려고 합니다. Chat GPT가 실제로 그렇게 할 준비가 되어 있다고 생각합니다. 그리고 최초의 대규모 ChatGPT 익스플로잇이 발생하는 것을 보는 것은 시간 문제라고 생각합니다.

팀 내쉬: 실제로 그런 일이 일어날 것이라고 어떻게 예상하십니까? 분명히 ChatGPT의 핵심은 서버에 대한 일련의 API 요청일 뿐이기 때문입니다. 그리고 당신은 나에게 악성 코드를 생성해달라는 요청을 보내고 있습니다. 돌려주는 것입니다. 이미 많은 사람들이 악성 코드를 생성하고 있습니다. 그렇다면 이미 존재하는 악성 코드보다 더 나쁜 코드를 만들려면 어떻게 해야 할까요?

LAWRENCE EDMONDSON: 정확히 맞습니다. 이미 배울 수 있는 대규모 저장소가 있습니다. 그래서 ChatGPT가 하는 일은 실제로 살펴보는 것입니다. 모델을 훈련시켜야 합니다. 그래서 시간이 지남에 따라 엔지니어는 누군가가 이렇게 말할 때 실제로 그들이 의미하는 바를 인식하도록 모델을 훈련시킵니다. 그러니 맥락을 이해하세요. 그래서 그것은 정확히 그렇지만 다른 방식입니다. 실제로 코드를 작성하고 그것이 실제로 무엇을 의미하는지 모델을 훈련시키는 것입니다. 그리고 일부 언어는 매우 쉽습니다. 따라서 PHP는 PHP로 코드를 작성하기가 매우 쉽습니다. 이러한 해석 언어는 훨씬 쉽습니다. 훨씬 더 지저분하지만 컴파일해야 하는 Java와 같은 작업을 수행하는 것과 비교하면 무슨 말인지 알겠습니까?

그래서 쉬운 방법은 chatGPT 3을 기반으로 모델을 만드는 것입니다. 이 모델을 실제로 훈련시켜 구문을 배우고 기본적인 컴퓨터 과학을 모두 배운 다음 가져옵니다. 이 NPM 패키지에는 이러한 익스플로잇이 있습니다. 찾아보고 실제로 방법을 찾으십시오. 그들은 이러한 취약점을 가지고 있습니다. 죄송합니다. 이러한 취약점을 악용하는 방법을 살펴보십시오. 장담컨대, 우리는 그런 일이 일어나는 것을 보는 데 그리 멀지 않습니다.

진행자: 감사합니다, 로렌스. 나는 그것이 매우 초기 영역이라고 생각합니다. 이 공간에서 흥미로운 점은 일반적으로 AI와 관련된 것입니다. 일반적으로 이러한 서명을 실제로 사용하여 방지하고 이를 통해 우리가 방지할 수 있는 방법을 알아보기 위해 사용할 수 있는지 여부에 대한 균형이 있습니다. 잘못된 코드 또는 취약한 코드를 작성합니다. 동시에 사람들이 말하는 것을 본 것처럼 Chat GPT로 5분 만에 첫 번째 플러그인을 작성했습니다. 더 빠르게? 하지만 두 가지 측면이 있다고 생각합니다.

코드 작성을 더 잘하면서 더 안전한 코드를 작성하기 위해 이러한 도구를 계속 활용하는 방법에 관한 것입니다. 그리고 팀, 그것이 당신의 열정 영역이라는 것을 압니다. 2023년에 Secure Code가 어떻게 발전하고 있는지, 그리고 그 공간에서 무엇을 하고 있는지에 대해 조금 더 이야기하고 싶습니까?

TIM NASH: 음, 여러 면에서 Chat GPT가 좋은 예입니다. 공격 벡터에 대해 생각하고 있었다면 솔직히 말해서 대량 스캔을 하고 악의적인 행위자로 많은 정보를 제공할 것이라고는 생각하지 않았습니다. 나는 그것을 시간을 절약하려고 노력하고 Chat GPT에 내용을 입력하고 그것을 버리는 평범한 코드 개발자라고 생각했습니다. 작성되고 생산되는 모든 코드를 완전히 이해하지 못하고 그것으로 가십시오. 이것은 단지 빠른 것일 뿐이고, 빠른 스크립트일 뿐이며, 모두 괜찮습니다. 그것은 생산에 들어가고 괜찮지 않고 모두 불타고 있습니다.

이제 이것은 관계없이 모든 개발자가 매일 수행하는 것과 정확히 동일합니다. 채팅 GPT는 이를 변경하지 않지만 약간 더 쉽게 활성화합니다. 그것은 줍니다 – 장벽이 적습니다.

SERGI ISASI: 예, Stack Overflow와 같은 것에서 복사하여 붙여넣는 것과는 다릅니다. 팀, 기본적으로 제가 코드에 대해 수행하는 작업은 이것이 전부입니다. 그러나 긍정적이든 부정적이든 확실히 효율성의 증가라고 생각합니다. 그러나 서명 기반 엔진이 따라잡을 수 없는 더 미묘한 변화와 더 빠른 활용이 가능하다고 생각합니다. 따라서 탐지를 수행할 때 과거에 본 것과 직접 일치하는 것이 아니라 과거에 본 것과 유사하게 보이는지 확인하는 시스템이 필요합니다. 그리고 그것은 실제로 감지 측면에 있으며 아마도 ML이나 AI 또는 무엇이라고 부르든 간에 가장 잘 제공될 것입니다.

우리는 자동화된 트래픽을 통해 기본적으로 봇을 배웠습니다. 서명 기반 탐지를 우회하는 방법을 배우는 가장 좋은 방법은 ML을 사용하는 것입니다. 그러나 이제 여러분은 이것이 나쁘다는 것을 절대적으로 알고 있습니다. 자동화될 가능성이 있거나 이전에 본 서명처럼 보이지만 정확히 일치하지는 않습니다.

진행자: 훌륭합니다. 감사합니다. 추가된 컨텍스트에 대해 Sergi와 Tim에게 감사합니다. 참석자 중에는 오늘 여기에 참석한 많은 개발자와 에이전시가 있습니다. 그리고 특히 위협 벡터 측면에서 시나리오가 변화함에 따라 많은 사람들이 모범 사례 수립에 대해 생각하고 있습니다. 사이트, 앱 또는 플랫폼을 구축할 때 또는 새 프로젝트를 시작할 때 권장할 수 있는 몇 가지 모범 사례는 무엇입니까? 그렇다면 사람들이 경계해야 할 것은 무엇입니까?

SERGI ISASI: 시작하겠습니다. 개발 측면보다 운영 측면에 더 가깝습니다. 우리가 여기서 설교하는 것 중 하나는 나쁜 일이 일어날 것이라고 가정하는 것입니다. 그래서 위반이 오고 있습니다. 당신은 그것에 놀라지 않을 수 없습니다. 언젠가는 일어날 가능성이 높습니다. 그리고 우리의 핵심 – 하나는 그것에 대한 런북을 만드는 것입니다. 따라서 그러한 일이 발생하면 감지 및 대응뿐만 아니라 고객에게 영향을 미치는 경우 고객과 소통하여 어떤 개인에게 연락하고 대응할 것인지 파악하십시오. 그런 점에서 우리가 Cloudflare에서 매우 잘하고 있으며 Cloudflare는 우리 브랜드의 일부였으며 이것이 우리에게 매우 도움이 되었다고 생각합니다. 그 일이 일어났습니다.

개방성은 소프트웨어 위반이든 사고 측면에서 저지른 실수든 어떤 일이 발생했을 때 고객과의 신뢰를 다시 구축하는 데 매우 중요했습니다. 그 뒤에 숨는 것은 결코 올바른 선택이 아닙니다.

진행자: 네.

JIMMY SQUIRES: 제 생각에는 또 다른 것이 있다고 생각합니다. 이제 모든 사람이 멀리 떨어져 있고 특히 개발 팀에 속해 있기 때문에 실제로 프로젝트 시작 시 화이트보드 및 건축 계획을 수행하는 데 시간을 할애하고 있습니다. 요구 사항에 바로 뛰어들고 개발 스토리를 시작하는 것은 매우 쉽지만 동료와 함께 시간을 보내어 이것이 어떻게 악용될 수 있는지 도전해 보십시오. 시나리오를 실행합니다. 우리는 응용 프로그램의 다른 부분을 강화하는 방법에 대해 많은 좋은 대화로 이어지는 많은 시나리오 계획을 수행합니다.

LAWRENCE EDMONDSON: 그리고 아는 사람이 있는지는 모르겠지만 MPM은 실제로 가장 큰 공유 리포지토리입니다. 애플리케이션 라이브러리의 단일 리포지토리가 가장 크지만 가장 큰 위험을 내포하기도 합니다. 따라서 NPM을 사용하는 경우 새 프로젝트를 시작할 때 우리가 매우 잘 알고 있는 한 가지는 취약점을 확인하고 제품에 푸시하는 버전을 잠그고 있는지 확인하는 것입니다. 업데이트를 할 때 호환 가능하면서도 매우 안전한지 확인합니다. 우리는 많은 취약점이 NPM을 통해 발생하는 것을 보았기 때문에 공개된 위협이 없습니다. 그래서 그것은 조심해야 할 한 가지입니다.

TIM NASH: 우리는 모든 것을 반복하고 있다고 생각합니다.

JIMMY SQUIRES: 계속하세요, 팀.

TIM NASH: 몇 년 동안 개발 주기에서 신뢰가 완전히 깨졌다는 생각에 이 모든 것을 반복하고 있다고 생각합니다. 사람들은 이제서야 깨닫고 있습니다. 예를 들어 WordPress에서 작업하는 PHP 개발자라면 작업과 필터를 호출하지만 이러한 작업과 필터를 신뢰해서는 안 됩니다. 들어오는 모든 데이터를 검증하고 확인해야 합니다. 소독해야 합니다. 그러나 그것이 데이터베이스에서 나올 때, 당신은 여전히 ​​그것을 신뢰해서는 안됩니다.

해당 데이터를 데이터베이스에 넣었더라도 나오는 데이터를 신뢰해서는 안 됩니다. NPM, 작성기 패키지 또는 다른 WordPress 플러그인과 같은 타사 라이브러리에 무언가를 전달하는 경우 즉시 제어할 수 있으므로 다시는 신뢰하지 않습니다. 그러나 그것이 다시 들어올 때 우리가 그것을 확인하더라도 우리는 여전히 그것을 신뢰하지 않습니다. 그리고 개발자로서 모든 데이터를 신뢰할 수 없고 완전히 격리해야 하며 주어진 모든 지점에서 보안 검사를 수행해야 한다는 사고방식을 가지고 들어가면 훨씬 더 안전한 시스템으로 약간 느린 시스템이 나올 수 있습니다. 약간 더 실망스러운 시스템과 현재 하고 있는 작업이 실제로 도움이 되는 것보다 더 많은 문제를 일으키지 않는지 확인하기 위해 훨씬 더 많은 테스트가 필요한 시스템을 마주할 수 있습니다.

진행자: 네.

TIM NASH: 복잡함을 더하면 훨씬 더 안전한 시스템이 됩니다. 그리고 대부분의 사람들에게 그것이 그들이 원하는 것입니다.

로렌스 에드먼슨: 네.

진행자: 네. 당신 말이 맞습니다. 통과하는 다른 코드를 신뢰하지 않는 것입니다. 그리고 Jimmy와 Sergi가 이야기한 바에 따르면, 계획이 있고 아키텍처 관점에서 또는 운영 관점에서 볼 수 있지만 보안 보안 코딩 메커니즘과 같은 것이든 사건 플레이북이 있는지 여부와 관계없이 모든 것을 전반적인 실행에 통합하는 것입니다. 그래서 Tim, 나는 당신 주변에서 더 많은 것을 듣고 싶습니다. 당신은 전 세계에서 많은 훈련을 하고 많은 교육을 합니다. 사람들이 프로젝트 작업을 시작할 때 흔히 볼 수 있는 실수나 여러분이 저질렀을 수도 있는 실수는 무엇입니까? 저는 그런 실수를 많이 했습니다.

TIM NASH: 내가 말하려는 모든 실수에 대해 내가 유죄라고 확신합니다. 그리고 가장 크고 가장 단순한 것은 좋은 사람이 되는 것입니다. 대부분의 개발자는 의도가 좋다고 가정합니다. 대부분의 사람들은 애플리케이션을 작성한 방식대로 애플리케이션을 사용할 것이라고 가정합니다. 지금은 꽤 자주 문서를 작성하지 않기 때문에 사용자는 처음부터 응용 프로그램을 사용하는 방법을 알지 못하지만 이는 별개의 문제입니다. 나쁜 배우가 들어와서 어떤 버그든 받아들이고 갈 것입니다. 그것은 버그가 아닙니다. 나쁜 배우에게는 그것이 기능입니다. 그것은 기회입니다. 개발자가 예상하지 못한 일을 하고 있으므로 이에 대한 잠재적인 경로가 있습니다.

그리고 전반적으로 여러분이 몇 번이고 보게 되는 것입니다. 오, 보세요, 단위 테스트 세트가 있습니다. 오 좋은. 그러나 당신은 긍정적인 것, 당신이 원하는 결과만을 테스트했습니다. 우리가 이러한 경계를 벗어나면 어떻게 되는지 테스트하지 않았습니다. 상사가 원하는 대로 작동하는지 확인하기 위해 방금 테스트했습니다. 그래서 당신이 실제로 가지고 있는 것은 수락 테스트, 모호한 수락 테스트입니다. 그런 다음 모든 기본 사항으로 돌아갑니다. 개발자로서 이것으로 뒷받침됩니다. 사물을 신뢰하지 마십시오. 특히 WordPress 개발자인 경우 WordPress에는 사람들에게 요청하는 모든 종류의 표준 보안 작업을 수행하기 위한 정말 좋은 도우미 기능이 있습니다.

그리고 그것들을 사용하는 방법을 교육하고 배우는 것입니다. 코드 리뷰를 할 때 같은 문제를 반복해서 보게 됩니다. 그리고 코드 조각에서 한 번 본다면 동일한 코드 세트에서 1,000번 볼 수 있습니다. 그리고 그것은 예를 들어, 페이지에 오래된 항목이 표시되도록 허용했습니다. 우리는 거기에 아무것도 있는지 여부를 확인하지 않았습니다. 예, 데이터베이스에 물건을 넣습니다. 아, 보세요, SQL 쿼리처럼 보일 수도 있고 아닐 수도 있습니다.

이러한 모든 종류의 문제는 쉽게 고칠 수 있으며 우리는 이미 고칠 도구를 제공했습니다. 그리고 우리가 그것들을 고치지 않는 이유는 종종 사람들이 이런 일이 일어나게 해서는 안 된다는 것을 모르기 때문도 아닙니다. 단지 우리가 게을러지고 일을 빨리 처리하고 스택 오버플로에서 코드를 가져오고 있기 때문입니다. 우리는 Chat GPT가 우리를 위해 일을 하도록 하고 있습니다. 우리는 일을 확인하지 않습니다. 그리고 이 상태에서 많은 보안 문제가 발생합니다. 서둘러야 합니다. 나는 서둘러야 한다. 서둘러야 해요, 이 일을 끝내야 해요. 다음 일로 넘어갈게요, 다음 일로 넘어갈게요.

이상하게도 많은 개발자들은 그들에게 시간과 공간을 주고 자신이 한 일을 실제로 확인하는 시간을 가져도 괜찮다고 말합니다. 나는 돌아와서 말할 것입니다. 글쎄요, 이 모든 것들과 개발자들은 소심해 보입니다. 예, 우리는 이 모든 것을 알고 있습니다. 우리는 시간이 없었습니다.

따라서 사람들에게 더 많은 시간을 주고 실제로 WordPress에 이미 있는 도구를 실제로 제공하기를 바랍니다. WordPress에는 WordPress 플러그인 또는 테마에서 발생할 수 있는 가장 일반적인 보안 문제에 대한 정말 훌륭한 도우미 기능 세트가 있습니다. 따라서 그것들을 배우고 실제로 구현하는 데 시간을 투자하는 것입니다.

진행자: 네. 그리고 저는 그것이 정말 강력하다고 생각합니다. 시간을 투자하세요. 대부분의 경우 개발자는 수정해야 할 사항을 알고 있습니다. 그래서 그들에게 시간을 줍니다. 그래서 저는 그 메시지가 정말 좋습니다. 그리고 Jimmy, 나는 당신이 이것을 당신의 대행사에서 당신의 워크플로우로 가져왔다는 것을 알고 있습니다. 구현한 안전한 워크플로우 사례에 대해 좀 더 이야기하고 싶습니까?

JIMMY SQUIRES: 네, 물론이죠. 그리고 실제로 Sergi가 계획을 갖고 있다고 말한 것, 실제로 개발 팀이 따라야 할 지침과 표준을 갖는 것으로 시작합니다. 매우 기본적으로 들릴 수 있지만 저는 수년 동안 많은 조직을 보았고 우리가 고용한 많은 엔지니어로부터 그것이 존재하지 않는다는 말을 들었습니다. 그들이 나온 직장에는 조직이 없었습니다.

그래서 우리가 하고 싶은 것은 표준 가이드라인 세트가 있고 모든 신입 엔지니어가 위에서 아래로 읽어야 한다는 것입니다. 너무 무거워서 소모품이 아닙니다. 우리는 그것을 마크다운에 보관하는 것을 좋아하므로 모두 저장소에 있습니다. 우리는 아마도 언젠가 그것을 소스로 공개할 것입니다. 거기에는 정말 독점적인 것이 없으며 모든 사람이 그것에 기여하도록 권장합니다. 모든 엔지니어에게 묻는 질문입니다.

따라서 가이드라인에서도 우리가 추가할 수 있는 구멍을 뚫고 더 나아질 수 있으며 지속적으로 성장할 수 있습니다. 그러나 OWASP와 같은 몇 가지 기본적인 것들과 함께 시간을 보내는 것은 정말 오래된 관행이지만 이러한 것들을 고려하여 애플리케이션으로 진행합니다. Tim이 말한 것과 같습니다. 정말 시간이 걸리고 시간을 들여도 괜찮습니다. AI 대화에 다시 한 가지 추가 포인트를 추가하고 싶었습니다. 지난 주에 몇 명의 엔지니어와 이야기를 나누다 실제로 이벤트가 있었습니다. 우리가 Chat GPT를 사용하는 이유는 실제로 단위 테스트입니다. 함수를 가져와서 흥미로운 방식으로 탐색하는 방법, 팀의 관점에서 해당 단위 테스트의 최고 작성자가 되지 않을 단위 테스트를 작성하기 위해 Chat GPT와 같은 것을 어떻게 활용할 수 있습니까? 예방적 방법으로 AI를 훨씬 더 많이 활용할 수 있는 곳이 바로 여기라고 생각합니다.

로렌스 에드먼슨: 네. 우리가 우리 편에서 하고 있는 일은 체크리스트와 플레이북이 훌륭하다고 생각합니다. 우리는 SonarQube와 같은 자동화된 도구를 사용하고 있으며 Linting을 통해 코드의 품질을 높이기 위해 보푸라기를 배치하고 있습니다. 뿐만 아니라 SonarQube를 사용하여 코드가 더 안전한지 확인하고 우리가 찾고 있는 것입니다. 취약점 및 이와 유사한 것들에 대해. 앞서 언급한 것처럼 일부 언어는 다른 언어보다 익스플로잇을 찾기가 더 쉽다고 생각합니다. 언어의 특성 때문입니다. 또한 해당 코드 기반에 기여하는 코더의 품질이 일반적으로 발생하는 특정 프레임워크는 일반적으로 오픈 소스에서 이를 볼 수 있습니다. CS는 그들이 무엇을 하고 있는지 정말로 알고 있습니다. 그래서 그것은 내가 본 것 중 하나입니다.

TIM NASH: 지적해야 할 것 같습니다. 저는 거의 매일 Stack OverFlow를 사용합니다. 그래서 우리는 모두 유죄입니다. 난리를 피우는 것은 좋지만 저는 그렇게 생각하지 않습니다. 제가 처음 코딩을 시작했을 때를 기억합니다. 나는 잡지를 받았고 잡지에서 코드를 입력하고 Enter 키를 누르고 있었습니다. 우리가 여전히 그렇게 하고 있고 스택 오버플로나 이와 유사한 것이 없다면 오늘날 웹이 실제로 작동한다고 상상할 수 없습니다.

Sergi: 아니요, 가속제입니다. 그리고 바라건대 AI는 그 다음 단계입니다. 하지만 네, 재미있는 밈입니다.

진행자: 감사합니다. 그래서 조금 이동합니다. Headless 및 Headless 구현을 중심으로 업계에서 많은 추진력이 일어나고 있습니다. 그리고 우리는 오늘 다른 채널이나 다른 세션에서 Headless에 대해 이야기하는 것을 보았습니다. 그래서 WP Engine에서 Atlas로 작업을 시작했을 때 많은 개발자를 만났고 보안은 항상 핵심 동기였습니다. 그렇다면 Headless의 보안은 어떻게 보십니까? 그리고 알고 있습니다, 지미, 이것은 당신이 그 주변에서 몇 가지 프로젝트를 수행한 영역입니다. 우리는 당신의 의견을 듣고 싶습니다.

JIMMY SQUIRES: 예, Headless에서 많은 작업을 수행합니다. 이 시점에서 거의 모든 프로젝트가 헤드리스 아키텍처 접근 방식을 취하고 있다고 생각합니다. 보안과 관련하여 몇 가지 지적하고 싶은 점이 있습니다. 첫 번째는 Headless 아키텍처를 선택할 때 일반적으로 처음부터 오픈 소스 진영에 자신을 더 많이 맡기는 것이라고 생각합니다. 물론 무엇이 더 안전한지, 오픈 소스인지 폐쇄 소스인지에 대한 많은 논쟁이 있습니다. 나는 본질적으로 OSS 프로젝트가 더 안전하다는 진영에 빠지는 경향이 있습니다. 따라서 거대한 커뮤니티가 있는 Next, WordPress와 같은 프레임워크를 선택하고 있습니다. 그리고 그것은 단지 노출을 통해 더 많은 보안을 제공하는 경향이 있습니다.

그래서 나는 그것이 하나라고 생각합니다. 두 번째는 정적 생성과 같은 것이라고 생각합니다. 따라서 구축된 많은 웹사이트와 제품에는 대규모 콘텐츠 관리의 동적 특성, 전통적인 의미의 단일 시스템이 필요하지 않습니다. Cloudflare와 같은 것을 활용하고 해당 애플리케이션의 많은 부분을 실제로 정적으로 생성하여 벡터 및 노출에 대한 공간을 줄일 수 있습니다. 그래서 우리는 그것의 열렬한 팬입니다. 그리고 물론 이를 통해 모든 성능 이점도 얻을 수 있습니다. 이것이 제가 헤드리스 아키텍처에 대해 만들고 싶었던 몇 가지 사항에 불과합니다. 그러나 보안 관점에서 우리가 좋아하는 더 많은 이유가 있습니다. 그러나 나는 그것들이 아마도 가장 큰 눈에 띄는 영역 중 두 가지라고 생각합니다.

TIM NASH: 일종의 레일 백을 통해 사람들에게 뒤쪽에 콘텐츠 관리 시스템이 여전히 있음을 상기시키고 싶습니다. Headless는 완전히 안전하다는 말을 너무 자주 듣습니다. 예, 하지만 웹 사이트에서 직접 호출하지 않기 때문에 여전히 거기에 있는 노출된 WordPress 인스턴스는 여전히 admin.yoursite.com에 있습니다. 그리고 당신은 그렇지 않습니다. 오 예, 이제 우리는 안전하므로 웹 사이트가 아니기 때문에 최신 상태로 유지하는 것에 대해 걱정할 필요가 없다는 특정한 믿음이 있습니다. 그것은 마치, 아니, 아니, 당신은 여전히 ​​당신이 이전에 하던 모든 일들이 필요하고 이제 우리는 다른 쪽도 가지고 있는 것과 같습니다.

Headless는 오랫동안 사용되어 많은 추진력을 얻고 있지만 WordPress에 REST API가 있기 전부터 이 작업을 수행했습니다. 우리는 최소한 정적 사이트를 얻기 위해 WordPress에서 Jekyll과 같은 콘텐츠로 콘텐츠를 밀어내고 있었습니다. 그렇게 하는 원래 이유는 WordPress 시스템이나 콘텐츠 관리 시스템을 네트워크 내부에 변경하는 것이었습니다. 그래서 당신은 그것을 잠그고 크고 무서운 웹에서 그것을 지킬 수 있습니다.

이제 우리는 Headless 솔루션을 제공하는 많은 호스팅 회사를 확보하고 있습니다. 그리고 그 인프라는 이제 다시 클라우드에 있습니다. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. 감사합니다. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. 감사합니다.