웹 프로젝트를 만들기 전에 스스로에게 물어봐야 할 다섯 가지 질문

기술 프로젝트가 실패하는 데는 백만 가지 이유가 있습니다. 잘못 계산된 비즈니스 모델, 과대평가된 수요 또는 거품이 이는 비용 등이 바로 그것입니다. 그러나 내 직업 생활 동안 나는 훌륭한 아이디어와 좋은 잠재력을 가진 프로젝트가 사소해 보이는 오류와 부주의로 인해 무너지는 것을 꽤 많이 보았습니다. 그리고 나는 이 이유가 적어도 개발자로서 나에게는 가장 쓰라린 이유라고 생각합니다. 이 기사에서는 내 경험을 공유하고 백엔드 개발자가 웹 애플리케이션에서 작업하면서 직면하는 문제와 과제를 분석하고 싶습니다. 종종 간과되는 핵심 사항을 강조하고 이러한 장애물을 최대한 효율적으로 해결하는 방법을 설명하겠습니다. 이것이 위험을 최소화하고 프로젝트의 성공 가능성을 크게 높이는 데 도움이 될 것이라고 확신합니다.

1. 코드에 비밀이 저장되어 있나요?

아무리 당연하게 들리더라도 이 점은 매우 중요합니다. 기밀 정보나 민감한 정보를 소스 코드에 절대 저장하지 마십시오. 위반은 재정적 손실 및 기타 심각한 문제로 이어질 수 있습니다. 코드에 저장해서는 안 되는 민감한 정보는 다음과 같습니다.

• 내부 또는 외부 서비스에 대한 API 키 및 액세스 토큰
• 데이터베이스 및 관리 시스템 비밀번호를 포함한 비밀번호 및 계정 데이터
• 암호화 키
• 민감한 데이터가 포함된 구성 파일
• 어머니의 결혼 전 이름이나 애완동물 이름과 같은 보안 질문에 대한 답변

이러한 정보를 프로젝트 코드에 저장하는 대신 환경 변수를 사용하세요. 보다 안전한 시스템을 위해서는 다음과 같은 강력한 비밀 저장소 솔루션을 사용하는 것이 좋습니다. HashiCorp 금고 . AWS 비밀 관리자 또는 GitHub 비밀 유용할 수도 있습니다. 비밀 저장 도구의 선택은 프로젝트 유형 및 규모, 팀의 경험, 기술 스택과 같은 요소에 따라 달라집니다.

애플리케이션 코드에 민감한 정보를 저장하는 것이 심각한 문제가 아니라고 생각한다면 다음을 고려하십시오. 2022년에만 GitHub에서 감지되었습니다. 170만 개 이상의 잠재적 비밀 공개 저장소에 노출됩니다. 개발자가 잠재적인 유출이 발생할 때까지 이를 인식하지 못하는 개인 프로젝트에 그러한 데이터 조각이 얼마나 많이 존재할 수 있는지 상상해 보십시오.

해결 방법: 지금 바로 프로젝트를 확인하세요.

이미 프로젝트가 있고 코드의 비밀이 걱정된다면 마음의 평화를 가져다 줄 수 있는 편리한 솔루션이 있습니다. 수동 점검은 시간이 많이 걸릴 수 있으므로 자동화가 핵심입니다. 유용한 도구는 다음과 같습니다.

• 트러플호그 : API 키 및 기타 민감한 데이터에 대한 커밋 기록을 스캔하여 Git 리포지토리에서 비밀을 검색합니다.
• GitLeaks : Git 리포지토리에서 비밀번호, API 키, 토큰과 같이 하드 코딩된 비밀을 감지합니다.
• GitGuardian : 로컬 또는 CI 환경에서 작동하여 350가지 이상의 비밀 유형 및 기타 보안 취약점을 찾아냅니다.
• GitHub 고급 보안 : 저장소에서 알려진 유형의 비밀을 자동으로 검색하고 발견되면 경고합니다.

이러한 도구는 단지 몇 가지 예일 뿐입니다. 다른 인기 있는 옵션은 다음과 같습니다. 소나큐브 그리고 체크막스 . 두 가지 모두 다양한 요구 사항과 예산을 충족할 수 있는 유료 및 무료 솔루션을 제공합니다. 여기서의 목표는 사용 가능한 모든 도구를 나열하는 것이 아니라 이러한 문제의 존재와 잠재적인 해결책을 강조하는 것입니다. 문제를 인식하는 것은 전투의 절반입니다. 이제 문제를 해결하는 데 시간을 할당하고 필요에 맞는 적절한 도구를 선택하는 것이 중요합니다.

2. 귀하의 도서관 라이센스에 대해 무엇을 알고 있습니까?

놀랍게도 이 주제는 거의 논의되지 않으며 일부 개발자는 타사 솔루션을 사용하면 회사에 법적 문제와 심각한 문제가 발생할 수 있다는 사실조차 인식하지 못합니다. 나를 믿지 못합니까? 다음 시나리오를 상상해 보십시오. 소규모 회사의 개발자가 GNU Affero 일반 공중 라이선스(AGPL) 상업용 웹 제품에서. 카피레프트 라이선스로서 AGPL은 그에 따라 출시된 코드를 사용하는 모든 소프트웨어가 동일한 조건에 따라 배포되도록 요구합니다. 이는 고유한 개발을 포함하여 모든 웹 애플리케이션의 코드가 공개되어 있어야 하며 무료로 사용하고 수정할 수 있어야 함을 의미합니다. 예제 제품은 상업용이므로 소스 코드를 공개하면 회사의 경쟁 우위와 비즈니스 모델이 심각하게 훼손될 수 있습니다.

상업적 사용을 명시적으로 금지하는 라이선스가 있는 라이브러리를 사용하는 프로젝트에서는 심각한 문제가 발생할 수도 있습니다. 그리고 라이센스가 전혀 없다면 상황은 그다지 나아지지 않습니다. 실제로 모든 코드는 기본적으로 저작권으로 보호되기 때문에 라이센스가 없으면 심각한 문제가 발생합니다. 라이선스는 특정 조건에서 사용자에게 코드를 사용할 수 있는 권리를 부여하지만, 라이선스가 없으면 코드가 공개적으로 액세스 가능하더라도 코드를 사용할 법적 근거가 전혀 없습니다.

라이센스 문제는 귀하의 관할권에 따라 다양한 방식으로 귀하에게 영향을 미칠 수 있다는 점은 주목할 가치가 있습니다. 이 문제는 특히 국제 저작권 계약을 체결한 국가와 관련이 있습니다. 예를 들어, 이 분야의 주요 국제 조약 중 하나인 문학 및 예술 작품 보호를 위한 베른 협약은 현재 약 180개국이 가입되어 있습니다. 따라서 명시적인 허가 없이 코드를 사용하는 것은 저작권법을 위반하는 것을 의미하며 전 세계 여러 곳에서 법적 싸움으로 이어질 수 있습니다. 그러나 이는 단지 모든 서면 및 불문 규칙을 위반하기 위해 '편안한' 국가로 이주해야 한다는 의미는 아닙니다. 서로를 존중하고, 누군가 자신의 개발이 특정 목적으로 사용되는 것을 원하지 않는다면 인간적인 관점에서도 그렇게 하지 않는 것이 가장 좋습니다.

해결 방법: 자동화된 확인 및 업데이트 사용

보시다시피 라이센스 및 저작권 문제는 복잡합니다. 자신과 회사를 미리 보호하려면 사용하는 라이브러리와 소프트웨어의 라이선스를 확인하는 것이 가장 좋습니다. 도서관의 경우 이는 그리 어렵지 않습니다. 최신 패키지 관리자에는 이미 이를 위한 도구가 있습니다. 예를 들어, PHP 작곡가에서는 ` 명령을 사용하여 이 작업을 수행할 수 있습니다. 작곡가 라이센스 `, Python에서 `를 통해 pip pip 라이센스 `, Golang에서는 `를 통해 이 정보를 얻을 수 있습니다. 이동 라이센스 `.

그리고 종속성을 업데이트할 때 이러한 명령을 호출하는 것을 잊지 마세요(이러한 확인을 자동화하는 것이 더 좋습니다). 연결된 라이브러리의 라이선스가 새 버전에서 변경될 수 있기 때문입니다.

3. 개발 버전 액세스가 제한되어 있나요?

웹 개발에서는 개발(dev), 품질 보증(QA), 스테이징, 프로덕션 등 여러 버전의 프로젝트가 있는 것이 일반적입니다. 나는 인터넷상의 모든 사람이 사이트 또는 웹 프로젝트의 개발/QA 및 준비 버전에 액세스할 수 있는 시나리오를 자주 접했습니다. 놀랍게도 테스트 버전은 기본 버전보다 검색 엔진에서 더 효과적으로 색인을 생성할 수 있으며, 이는 일반적으로 제품에 해를 끼칩니다.

여기서 가장 큰 문제는 테스트 버전에 버그나 민감한 정보가 포함될 수 있고 심지어 손상될 수도 있다는 것입니다. 또한 베타 버전은 일반적으로 최종 프로덕션보다 해킹에 더 취약합니다. 즉, 가용성이 높을수록 공격자가 중요한 데이터, 내부 코드 또는 서버 자체에 액세스할 위험이 높아집니다. API의 테스트 버전에 대한 무단 액세스는 매우 위험할 수 있으므로 모바일 애플리케이션과 같은 백엔드를 개발하는 경우 특히 그렇습니다.

보안 위험 외에도 중복된 웹페이지는 검색 엔진 순위에 부정적인 영향을 미칠 수 있습니다. Google과 같은 검색 엔진은 이러한 중복 항목을 바람직하지 않은 콘텐츠로 간주하여 잠재적으로 프로젝트 원본 페이지의 순위를 낮추거나 색인에서 완전히 제거할 수도 있습니다.

솔루션: 처음부터 보안 전략을 고안하십시오.

도메인을 인색하지 마십시오. 온라인으로 액세스할 수 있는 테스트 버전이 필요한 경우 해당 버전에 맞는 별도의 도메인을 구입하세요. 이 간단하면서도 효과적인 방법은 공격자가 일반적으로 하위 도메인을 먼저 확인하기 때문에 보안 위험을 줄여줍니다. 기본 리소스의 하위 도메인에서 테스트 버전을 호스팅하면 쉽게 대상이 됩니다.

모든 테스트 버전에 대한 액세스를 제한합니다. 개발, QA, 스테이징 및 기타 버전이 공개적으로 액세스할 수 없는지 확인하세요. 예를 들어, VPN을 통해서만 액세스할 수 있도록 구성하세요. 이렇게 하면 테스트 도메인이 악의적인 행위자에게 알려지더라도 무단 액세스 가능성이 줄어듭니다.

테스트 버전이 색인화되지 않도록 보호하세요. 테스트 버전이 VPN을 통해서만 액세스할 수 있고 별도의 비밀 도메인에서 호스팅되는 경우에도 `robots.txt` 파일 또는 `noindex` 메타 태그를 사용하여 검색 엔진 색인 생성으로부터 보호하세요. 검색 엔진이 때때로 예상치 못한 방식으로 이러한 페이지를 찾고 색인을 생성할 수 있으므로 이 단계는 매우 중요합니다.

4. 실제 IP 주소가 숨겨져 있나요? 사용하지 않는 포트가 닫혀 있습니까?

매우 중요하고 힘든 교훈을 통해 확립되었음에도 불구하고 많은 개발자가 간과하는 경향이 있는 보안 규칙이 있습니다. 그러한 규칙 중 하나는 항상 프로젝트의 실제 IP 주소를 숨기는 것입니다. 도메인 이름을 통해 서버의 IP 주소를 확인할 수 있는 경우 다음과 같은 여러 문제가 발생할 수 있습니다.

• DDoS 공격: 공격자는 프로젝트의 실제 IP 주소를 알면 서버에 DDoS(분산 서비스 거부) 공격을 시작할 수 있습니다. 예를 들어, DNS 반사 증폭 공격은 공개 DNS 서버의 엄청난 양의 응답으로 서버를 압도하여 사용자가 서비스를 사용할 수 없게 만들고 상당한 재정적 손실을 초래할 수 있습니다.

  
  

• 잠재적인 취약점 식별: 아마추어뿐만 아니라 심각한 해커도 열린 포트와 네트워크에 노출된 소프트웨어를 검사하여 약점을 찾아 악용할 수 있습니다. MongoDB와 같이 잘 알려진 서비스에서도 잘못된 구성으로 인해 심각한 데이터 침해가 발생했습니다. 이러한 문제 중 대부분은 실제 IP 주소를 숨기는 것만으로도 피할 수 있습니다.

해결책: 잠재적인 공격자의 삶을 더욱 복잡하게 만듭니다.

서버의 실제 IP 주소를 숨기면 공격자가 시스템을 표적으로 삼는 것이 훨씬 더 어려워집니다. 여기에서는 CDN(Content Delivery Network) 또는 DDoS 보호 서비스를 사용하는 것이 매우 효과적일 수 있습니다. 인기 있는 옵션은 다음과 같습니다. 클라우드플레어 는 CDN 기능과 DDoS 보호를 모두 무료로 제공할 뿐만 아니라 다음과 같은 서비스도 제공합니다. 임페르바 (이전 Incapsula) 유사한 기능을 제공하며 큐레이터 는 웹 애플리케이션 방화벽으로 웹 앱을 보호하는 데 특화되어 있지만 비용이 발생할 수 있습니다.

이러한 도구는 보안을 크게 향상시킬 수 있지만 명심해야 할 추가 고려 사항이 있습니다.

• 이메일 헤더 IP 누출: 이메일을 보내는 데 기본 서버를 사용하는 경우 이메일 헤더에 실제 IP 주소가 노출되어 보안 노력이 수포로 돌아갈 수 있습니다.

  
  

• IP 기록 및 Whois 요청: 다음과 같은 서비스 DNS 기록 또는 후이즈 요청 도메인과 관련된 과거 IP 주소를 공개할 수 있습니다. 실제 IP가 작업 도메인에 연결된 적이 있다면 이를 변경해야 합니다.

  
  

• DDoS 보호 및 API 엔드포인트: API 엔드포인트 역할을 하는 도메인에 대해 DDoS 보호를 사용할 때는 주의하세요. 보호 시스템은 JSON/XML 응답을 HTML 코드로 대체하여 클라이언트 측 애플리케이션의 기능을 방해할 수 있는 사용자 확인 단계를 도입할 수 있습니다.

  
  

• 발신 API 요청: 서버가 타사 API에 요청을 보낼 때 실수로 IP 주소가 공개될 수 있습니다. 이러한 요청에 프록시 서버를 사용하면 공격의 여파를 처리하는 것보다 프록시를 변경하는 것이 더 쉽기 때문에 도움이 될 수 있습니다.

프로젝트의 실제 IP 주소를 숨기는 것이 만병통치약은 아니라는 점을 기억하는 것이 중요합니다. 가능하면 외부 네트워크에서 소프트웨어가 사용하는 포트를 닫는 것이 중요합니다. 표준 포트를 변경하는 것은 논쟁의 여지가 있는 관행입니다. 일부 전문가들은 이것이 큰 이점 없이 설정을 복잡하게 한다고 주장합니다. 종종 네트워크 TCP 연결 대신 Unix 소켓을 통해 상호 작용하도록 소프트웨어를 구성하는 것이 더 좋습니다(프로젝트와 소프트웨어가 모두 동일한 서버에서 실행되는 경우). 이 접근 방식은 상호 작용 속도를 높일 뿐만 아니라 개방형 포트가 필요하지 않아 보안도 강화합니다.

별도의 서버에 있는 데이터베이스 관리 시스템(DBMS) 또는 기타 내부 서비스의 경우 엄격하게 제어하는 특정 IP 주소로 액세스가 제한되는지 확인하세요. 이 설정은 중요한 시스템에 대한 무단 액세스를 방지하고 보안 계층을 추가하며 외부 공격 및 데이터 유출 위험을 최소화합니다.

5. 프로젝트 종속성과 소프트웨어를 업데이트합니까?

이 조언은 매우 간단하지만 종종 간과되기도 합니다. 프로젝트의 종속성과 서버 소프트웨어를 정기적으로 업데이트하세요. 오래되고 취약한 코드는 이를 쉽게 악용할 수 있는 공격자의 꿈입니다.

해결책: 업데이트 자동화

모든 것을 수동으로 업데이트할 필요는 없습니다. 많은 자동화 도구가 도움이 될 수 있습니다. 예를 들어, 디펜다봇 GitHub에서는 오래되었거나 취약한 종속성을 자동으로 감지하고 업데이트를 제안합니다.

보안 인증서 갱신을 자동화하는 것도 중요합니다. 당신이 사용하는 경우 암호화하자 인증서 갱신을 자동화할 수 있습니다. 인증서봇 . 만료된 인증서로 인해 상당한 어려움이 발생할 수 있지만 인증서 갱신을 자동화하는 것은 간단한 작업입니다.

\서버 소프트웨어에도 동일한 원칙이 적용됩니다. Linux, 특히 Debian/Ubuntu 기반 배포판을 사용하는 경우, 무인 업그레이드 작업을 쉽게 처리할 수 있습니다. 서버가 많은 대규모 프로젝트의 경우 다음과 같은 도구가 필요합니다. 앤서블 , 요리사 , 인형 , 또는 소금 사용할 수 있습니다.

마지막 생각들

여기에 제공된 팁은 백엔드 개발자가 기억해야 할 사항의 일부일 뿐입니다. 나는 다음과 같은 일반적인 주제에 비해 중요하지만 덜 자주 논의되는 주제를 강조하기로 선택했습니다. SQL 주입 또는 CSRF 공격.

웹 애플리케이션 보안에 대해 더 깊이 이해하려면 다음을 살펴보세요. OWASP 재단 , 귀중한 자원을 제공하는 비영리 단체입니다. 그만큼 OWASP 상위 10위 웹사이트에서 제공되는 문서에는 가장 일반적이고 중요한 웹 애플리케이션 보안 위험이 나열되어 있습니다. 덜 알려졌지만 똑같이 위험한 공격에 대한 정보도 찾을 수 있습니다.

저는 개발자 커뮤니티가 통찰력과 경험을 공유하는 데 있어 지식이 풍부하고 지원적이어야 한다고 믿습니다. 따라서 저는 백엔드 개발에 종사하는 모든 사람에게 귀중한 관찰과 의견을 공유하도록 모든 사람을 초대합니다!