다음을 통해 공유


보안 프레임: 통신 보안 | 완화

제품/서비스 조항
Azure 이벤트 허브
Dynamics CRM
Azure Data Factory
ID 서버
웹 응용 프로그램
데이터베이스
Azure Storage
모바일 클라이언트
WCF
웹 API
Azure Cache for Redis
IoT 필드 게이트웨이
IoT 클라우드 게이트웨이

SSL/TLS를 사용하여 Event Hub에 대한 보안 통신

제목 세부 정보
구성 요소 Azure Event Hub
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 Event Hubs 인증 및 보안 모델 개요
단계 SSL/TLS를 사용하여 이벤트 허브에 대한 AMQP 또는 HTTP 연결 보호

서비스 계정 권한을 확인하고 사용자 지정 서비스 또는 ASP.NET Pages가 CRM의 보안을 준수하는지 확인합니다.

제목 세부 정보
구성 요소 Dynamics CRM
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 해당 없음(N/A)
단계 서비스 계정 권한을 확인하고 사용자 지정 서비스 또는 ASP.NET Pages가 CRM의 보안을 준수하는지 확인합니다.

온-프레미스 SQL Server를 Azure Data Factory에 연결하는 동안 데이터 관리 게이트웨이 사용

제목 세부 정보
구성 요소 Azure Data Factory
SDL 단계 배치
적용 가능한 기술 일반
특성 연결된 서비스 유형 - Azure 및 온-프레미스
참조 온-프레미스와 Azure Data Factory 간에 데이터 이동
단계

DMG(데이터 관리 게이트웨이) 도구는 corpnet 또는 방화벽 뒤에서 보호되는 데이터 원본에 연결해야 합니다.

  1. 컴퓨터를 잠그면 DMG 도구가 격리되고 오작동하는 프로그램이 데이터 원본 컴퓨터에서 손상되거나 스누핑되지 않도록 방지할 수 있습니다. (예: 최신 업데이트를 설치하고, 필요한 최소 포트를 사용하도록 설정, 제어된 계정 프로비전, 감사 사용, 디스크 암호화 사용 등)
  2. 데이터 게이트웨이 키는 자주 또는 DMG 서비스 계정 암호가 갱신될 때마다 회전해야 합니다.
  3. Link Service를 통한 데이터 전송은 암호화되어야 합니다.

ID 서버에 대한 모든 트래픽이 HTTPS 연결을 통해 수행되는지 확인합니다.

제목 세부 정보
구성 요소 ID 서버
SDL 단계 배치
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 해당 없음(N/A)
단계 기본적으로 IdentityServer는 들어오는 모든 연결이 HTTPS를 통해 오도록 요구합니다. IdentityServer와의 통신은 보안 전송을 통해서만 수행되어야 합니다. 이 요구 사항을 완화할 수 있는 TLS 오프로드와 같은 특정 배포 시나리오가 있습니다. 자세한 내용은 참조의 ID 서버 배포 페이지를 참조하세요.

SSL, TLS 및 DTLS 연결을 인증하는 데 사용되는 X.509 인증서 확인

제목 세부 정보
구성 요소 웹 애플리케이션
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 해당 없음(N/A)
단계

SSL, TLS 또는 DTLS를 사용하는 애플리케이션은 연결하는 엔터티의 X.509 인증서를 완전히 확인해야 합니다. 여기에는 다음에 대한 인증서 확인이 포함됩니다.

  • 도메인 이름
  • 유효 날짜(시작 날짜와 만료 날짜 모두)
  • 해지 상태
  • 사용량(예: 서버에 대한 서버 인증, 클라이언트용 클라이언트 인증)
  • 신뢰 체인. 인증서는 플랫폼에서 신뢰하거나 관리자가 명시적으로 구성한 루트 CA(인증 기관)에 연결해야 합니다.
  • 인증서 공개 키의 키 길이는 2048비트여야 >합니다.
  • 해시 알고리즘은 SHA256 이상이어야 합니다.

Azure App Service에서 사용자 지정 도메인에 대한 TLS/SSL 인증서 구성

제목 세부 정보
구성 요소 웹 애플리케이션
SDL 단계 빌드
적용 가능한 기술 일반
특성 환경 유형 - Azure
참조 Azure App Service에서 앱에 HTTPS 사용
단계 기본적으로 Azure는 *.azurewebsites.net 도메인에 대한 와일드카드 인증서를 사용하여 모든 앱에 대해 HTTPS를 이미 사용하도록 설정합니다. 그러나 모든 와일드카드 도메인과 마찬가지로 자체 인증서가 있는 사용자 지정 도메인을 사용하는 것만큼 안전하지는 않습니다. 배포된 앱에 액세스할 사용자 지정 도메인에 대해 TLS를 사용하도록 설정하는 것이 좋습니다.

Azure App Service로의 모든 트래픽을 HTTPS 연결로 강제하다.

제목 세부 정보
구성 요소 웹 애플리케이션
SDL 단계 빌드
적용 가능한 기술 일반
특성 환경 유형 - Azure
참조 Azure App Service에 HTTPS 적용
단계

Azure는 이미 *.azurewebsites.net 도메인에 대한 와일드카드 인증서를 사용하여 Azure App Services에 대해 HTTPS를 사용하도록 설정하지만 HTTPS를 적용하지는 않습니다. 방문자는 여전히 HTTP를 사용하여 앱에 액세스할 수 있으므로 앱의 보안을 손상시킬 수 있으므로 HTTPS를 명시적으로 적용해야 합니다. ASP.NET MVC 애플리케이션은 보안되지 않은 HTTP 요청을 HTTPS를 통해 다시 전송하도록 강제하는 RequireHttps 필터 를 사용해야 합니다.

또는 Azure App Service에 포함된 URL 다시 쓰기 모듈을 사용하여 HTTPS를 적용할 수 있습니다. URL 다시 쓰기 모듈을 사용하면 개발자가 요청을 애플리케이션에 전달하기 전에 들어오는 요청에 적용되는 규칙을 정의할 수 있습니다. URL 다시 쓰기 규칙은 애플리케이션의 루트에 저장된 web.config 파일에 정의됩니다.

예시

다음 예제에는 들어오는 모든 트래픽이 HTTPS를 사용하도록 강제하는 기본 URL 다시 쓰기 규칙이 포함되어 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Force HTTPS" enabled="true">
          <match url="(.*)" ignoreCase="false" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

이 규칙은 사용자가 HTTP를 사용하여 페이지를 요청할 때 HTTP 상태 코드 301(영구 리디렉션)을 반환하여 작동합니다. 301은 요청을 방문자가 요청한 것과 동일한 URL로 리디렉션하지만 요청의 HTTP 부분을 HTTPS로 바꿉니다. 예를 들어, HTTP://contoso.comHTTPS://contoso.com로 리다이렉트됩니다.

HSTS(HTTP Strict Transport Security) 사용

제목 세부 정보
구성 요소 웹 애플리케이션
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 OWASP HTTP 엄격한 전송 보안 참고 자료
단계

HSTS(HTTP Strict Transport Security)는 특수 응답 헤더를 사용하여 웹 애플리케이션에서 지정하는 옵트인 보안 향상 기능입니다. 지원되는 브라우저가 이 헤더를 받으면 브라우저는 HTTP를 통해 지정된 도메인으로 통신이 전송되는 것을 방지하고 대신 HTTPS를 통해 모든 통신을 보냅니다. 또한 브라우저의 프롬프트를 통해 HTTPS 클릭을 방지합니다.

HSTS를 구현하려면 코드 또는 구성에서 웹 사이트에 대해 다음 응답 헤더를 전역적으로 구성해야 합니다. Strict-Transport-Security: max-age=300; includeSubDomains HSTS는 다음 위협을 해결합니다.

  • 사용자가 책갈피에 추가하거나 https://example.com를 수동으로 입력하는 경우 중간자 공격자의 영향을 받을 수 있습니다. HSTS는 HTTP 요청을 자동으로 대상 도메인의 HTTPS로 리디렉션합니다.
  • 순수 HTTPS로 의도된 웹 애플리케이션은 실수로 HTTP 링크를 포함하거나 HTTP를 통해 콘텐츠를 제공합니다. HSTS는 대상 도메인에 대한 HTTP 요청을 HTTPS로 자동으로 리디렉션합니다.
  • 중간의 한 공격자가 잘못된 인증서를 사용하여 피해자 사용자의 트래픽을 가로채려고 시도하고 사용자가 잘못된 인증서를 수락하기를 희망합니다. HSTS는 사용자가 잘못된 인증서 메시지를 재정의하는 것을 허용하지 않습니다.

SQL Server 연결 암호화 및 인증서 유효성 검사 확인

제목 세부 정보
구성 요소 데이터베이스
SDL 단계 빌드
적용 가능한 기술 SQL Azure
특성 SQL 버전 - V12
참조 SQL Database에 대한 보안 연결 문자열 작성 모범 사례
단계

SQL Database와 클라이언트 애플리케이션 간의 모든 통신은 항상 SSL(Secure Sockets Layer)으로 알려진 TLS(전송 계층 보안)를 사용하여 암호화됩니다. SQL Database는 암호화되지 않은 연결을 지원하지 않습니다. 애플리케이션 코드 또는 도구를 사용하여 인증서의 유효성을 검사하려면 명시적으로 암호화된 연결을 요청하고 서버 인증서를 신뢰하지 않습니다. 애플리케이션 코드 또는 도구가 암호화된 연결을 요청하지 않으면 암호화된 연결이 계속 수신됩니다.

그러나 서버 인증서의 유효성을 검사하지 않을 수 있으므로 "중간에 있는 사람" 공격에 취약합니다. ADO.NET 애플리케이션 코드를 사용하여 인증서의 유효성을 검사하려면 데이터베이스 연결 문자열을 설정하고 Encrypt=TrueTrustServerCertificate=False 설정합니다. SQL Server Management Studio를 통해 인증서의 유효성을 검사하려면 서버에 연결 대화 상자를 엽니다. 연결 속성 탭에서 연결 암호화 클릭

SQL Server에 암호화된 통신 강제 적용

제목 세부 정보
구성 요소 데이터베이스
SDL 단계 빌드
적용 가능한 기술 OnPrem
특성 SQL 버전 - MsSQL2016, SQL 버전 - MsSQL2012, SQL 버전 - MsSQL2014
참조 데이터베이스 엔진에 암호화된 연결 사용
단계 TLS 암호화를 사용하면 네트워크에서 SQL Server 인스턴스와 애플리케이션 간에 전송되는 데이터에 관한 보안이 강화됩니다.

Azure Storage에 대한 통신이 HTTPS를 통해 이루어지는지 확인

제목 세부 정보
구성 요소 Azure Storage
SDL 단계 배치
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 Azure Storage Transport-Level 암호화 – HTTPS 사용
단계 전송 중인 Azure Storage 데이터의 보안을 보장하려면 REST API를 호출하거나 스토리지의 개체에 액세스할 때 항상 HTTPS 프로토콜을 사용합니다. 또한 Azure Storage 개체에 대한 액세스를 위임하는 데 사용할 수 있는 공유 액세스 서명에는 공유 액세스 서명을 사용할 때 HTTPS 프로토콜만 사용할 수 있도록 지정하여 SAS 토큰으로 링크를 보내는 모든 사용자가 적절한 프로토콜을 사용하도록 하는 옵션이 포함되어 있습니다.

HTTPS를 사용할 수 없는 경우 Blob을 다운로드한 후 MD5 해시 유효성 검사

제목 세부 정보
구성 요소 Azure Storage
SDL 단계 빌드
적용 가능한 기술 일반
특성 저장유형 - Blob
참조 Windows Azure Blob MD5 개요
단계

Windows Azure Blob Service는 애플리케이션 및 전송 계층 모두에서 데이터 무결성을 보장하는 메커니즘을 제공합니다. 어떤 이유로든 HTTPS 대신 HTTP를 사용해야 하고 블록 Blob으로 작업하는 경우 MD5 검사를 사용하여 전송되는 Blob의 무결성을 확인할 수 있습니다.

이렇게 하면 네트워크/전송 계층 오류로부터 보호하는 데 도움이 되지만 반드시 중간 공격이 있는 것은 아닙니다. 전송 수준 보안을 제공하는 HTTPS를 사용할 수 있는 경우 MD5 검사를 사용하는 것은 중복되고 불필요합니다.

SMB 3.x 호환 클라이언트를 사용하여 Azure 파일 공유로 전송 중인 데이터 암호화 보장

제목 세부 정보
구성 요소 모바일 클라이언트
SDL 단계 빌드
적용 가능한 기술 일반
특성 저장 유형 - 파일
참조 Azure Files, Windows 클라이언트에 대한 Azure Files SMB 지원
단계 Azure Files는 REST API를 사용할 때 HTTPS를 지원하지만 VM에 연결된 SMB 파일 공유로 더 일반적으로 사용됩니다. SMB 2.1은 암호화를 지원하지 않으므로 Azure의 동일한 지역 내에서만 연결이 허용됩니다. 그러나 SMB 3.x는 암호화를 지원하며 Windows Server 2012 R2, Windows 8, Windows 8.1 및 Windows 10에서 사용할 수 있으므로 지역 간 액세스 및 데스크톱에서의 액세스도 허용합니다.

인증서 고정 구현

제목 세부 정보
구성 요소 Azure Storage
SDL 단계 빌드
적용 가능한 기술 일반, Windows Phone
특성 해당 없음(N/A)
참조 인증서 및 공개 키 고정
단계

인증서 고정은 MITM(Man-In-The-Middle) 공격을 방어합니다. 핀닝은 호스트를 예상 X509 인증서 또는 공개 키와 연결하는 프로세스입니다. 인증서 또는 공개 키가 호스트에 대해 알려지거나 표시되면 인증서 또는 공개 키가 호스트에 연결되거나 '고정'됩니다.

따라서 악의적 사용자가 TLS MITM 공격을 시도하면 TLS 핸드셰이크 중에 공격자 서버의 키가 고정된 인증서의 키와 다르며 요청이 삭제되므로 ServicePointManager의 ServerCertificateValidationCallback 대리자를 구현하여 MITM 인증서 고정을 방지할 수 있습니다.

예시

using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography;

namespace CertificatePinningExample
{
    class CertificatePinningExample
    {
        /* Note: In this example, we're hardcoding the certificate's public key and algorithm for 
           demonstration purposes. In a real-world application, this should be stored in a secure
           configuration area that can be updated as needed. */

        private static readonly string PINNED_ALGORITHM = "RSA";

        private static readonly string PINNED_PUBLIC_KEY = "3082010A0282010100B0E75B7CBE56D31658EF79B3A1" +
            "294D506A88DFCDD603F6EF15E7F5BCBDF32291EC50B2B82BA158E905FE6A83EE044A48258B07FAC3D6356AF09B2" +
            "3EDAB15D00507B70DB08DB9A20C7D1201417B3071A346D663A241061C151B6EC5B5B4ECCCDCDBEA24F051962809" +
            "FEC499BF2D093C06E3BDA7D0BB83CDC1C2C6660B8ECB2EA30A685ADE2DC83C88314010FFC7F4F0F895EDDBE5C02" +
            "ABF78E50B708E0A0EB984A9AA536BCE61A0C31DB95425C6FEE5A564B158EE7C4F0693C439AE010EF83CA8155750" +
            "09B17537C29F86071E5DD8CA50EBD8A409494F479B07574D83EDCE6F68A8F7D40447471D05BC3F5EAD7862FA748" +
            "EA3C92A60A128344B1CEF7A0B0D94E50203010001";


        public static void Main(string[] args)
        {
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://azure.microsoft.com");
            request.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
            {
                if (certificate == null || sslPolicyErrors != SslPolicyErrors.None)
                {
                    // Error getting certificate or the certificate failed basic validation
                    return false;
                }

                var targetKeyAlgorithm = new Oid(certificate.GetKeyAlgorithm()).FriendlyName;
                var targetPublicKey = certificate.GetPublicKeyString();
                
                if (targetKeyAlgorithm == PINNED_ALGORITHM &&
                    targetPublicKey == PINNED_PUBLIC_KEY)
                {
                    // Success, the certificate matches the pinned value.
                    return true;
                }
                // Reject, either the key or the algorithm does not match the expected value.
                return false;
            };

            try
            {
                var response = (HttpWebResponse)request.GetResponse();
                Console.WriteLine($"Success, HTTP status code: {response.StatusCode}");
            }
            catch(Exception ex)
            {
                Console.WriteLine($"Failure, {ex.Message}");
            }
            Console.WriteLine("Press any key to end.");
            Console.ReadKey();
        }
    }
}

HTTPS 사용 - 보안 전송 채널

제목 세부 정보
구성 요소 WCF (Windows Communication Foundation)
SDL 단계 빌드
적용 가능한 기술 NET Framework 3
특성 해당 없음(N/A)
참조 MSDN, Fortify, 영국
단계 애플리케이션 구성은 중요한 정보에 대한 모든 액세스에 HTTPS가 사용되는지 확인해야 합니다.
  • 설명: 애플리케이션이 중요한 정보를 처리하고 메시지 수준 암호화를 사용하지 않는 경우 암호화된 전송 채널을 통해서만 통신할 수 있어야 합니다.
  • 권장 사항: HTTP 전송을 사용하지 않도록 설정하고 대신 HTTPS 전송을 사용하도록 설정합니다. 예를 들어 <httpTransport/><httpsTransport/>로 바꾸세요. 보안 채널을 통해서만 애플리케이션에 액세스할 수 있도록 네트워크 구성(방화벽)을 사용하지 마세요. 철학적 관점에서 애플리케이션은 보안을 위해 네트워크에 의존해서는 안 됩니다.

실질적인 관점에서 볼 때 네트워크 보안을 담당하는 사람들은 애플리케이션이 진화함에 따라 항상 애플리케이션의 보안 요구 사항을 추적하지는 않습니다.

WCF: 메시지 보안 보호 수준을 EncryptAndSign으로 설정

제목 세부 정보
구성 요소 WCF (Windows Communication Foundation)
SDL 단계 빌드
적용 가능한 기술 .NET Framework 3
특성 해당 없음(N/A)
참조 MSDN
단계
  • 설명: 보호 수준이 "없음"으로 설정되면 메시지 보호를 사용하지 않도록 설정합니다. 기밀성과 무결성은 적절한 수준의 설정으로 달성됩니다.
  • 권장 사항:
    • when Mode=None - 메시지 보호를 사용하지 않도록 설정
    • when Mode=Sign - 서명하지만 메시지를 암호화하지 않습니다. 데이터 무결성이 중요한 경우 사용해야 합니다.
    • when Mode=EncryptAndSign - 메시지 서명 및 암호화

기밀성 문제 없이 정보 무결성의 유효성을 검사해야 하는 경우에만 암호화를 해제하고 메시지에 서명하는 것이 좋습니다. 이는 원래 보낸 사람 유효성을 검사해야 하지만 중요한 데이터가 전송되지 않는 작업 또는 서비스 계약에 유용할 수 있습니다. 보호 수준을 줄일 때는 메시지에 개인 데이터가 포함되지 않도록 주의해야 합니다.

예시

다음 예제에서는 메시지만 서명하도록 서비스 및 작업을 구성합니다. 서비스 계약 예제 ProtectionLevel.Sign: 다음은 서비스 계약 수준에서 ProtectionLevel.Sign을 사용하는 예제입니다.

[ServiceContract(Protection Level=ProtectionLevel.Sign] 
public interface IService 
  { 
  string GetData(int value); 
  } 

예시

세분화된 컨트롤의 ProtectionLevel.Sign 작업 계약 예제: 다음은 OperationContract 수준에서 사용하는 ProtectionLevel.Sign 예제입니다.

[OperationContract(ProtectionLevel=ProtectionLevel.Sign] 
string GetData(int value);

WCF: 최소 권한 계정을 사용하여 WCF 서비스 실행

제목 세부 정보
구성 요소 WCF (Windows Communication Foundation)
SDL 단계 빌드
적용 가능한 기술 .NET Framework 3
특성 해당 없음(N/A)
참조 MSDN
단계
  • 설명: 관리자 또는 높은 권한 계정으로 WCF 서비스를 실행하지 마세요. 서비스가 손상되는 경우 높은 영향을 줍니다.
  • 권장 사항: 애플리케이션의 공격 노출 영역을 줄이고 공격을 받을 경우 잠재적인 손상을 줄일 수 있으므로 최소 권한 계정을 사용하여 WCF 서비스를 호스트합니다. 서비스 계정에 MSMQ, 이벤트 로그, 성능 카운터 및 파일 시스템과 같은 인프라 리소스에 대한 추가 액세스 권한이 필요한 경우 WCF 서비스가 성공적으로 실행될 수 있도록 이러한 리소스에 적절한 권한을 부여해야 합니다.

서비스가 원래 호출자를 대신하여 특정 리소스에 액세스해야 하는 경우 가장 및 위임을 사용하여 다운스트림 권한 부여 확인을 위해 호출자의 ID를 전달합니다. 개발 시나리오에서는 권한이 감소된 특수한 기본 제공 계정인 로컬 네트워크 서비스 계정을 사용합니다. 프로덕션 시나리오에서 최소 권한의 사용자 지정 도메인 서비스 계정을 만듭니다.

HTTPS 연결을 통해 Web API에 대한 모든 트래픽 강제 적용

제목 세부 정보
구성 요소 인터넷 응용 프로그램 인터페이스
SDL 단계 빌드
적용 가능한 기술 MVC5, MVC6
특성 해당 없음(N/A)
참조 Web API 컨트롤러에 SSL 적용
단계 애플리케이션에 HTTPS와 HTTP 바인딩이 모두 있는 경우 클라이언트는 여전히 HTTP를 사용하여 사이트에 액세스할 수 있습니다. 이를 방지하려면 작업 필터를 사용하여 보호된 API에 대한 요청이 항상 HTTPS를 통해 수행되도록 합니다.

예시

다음 코드는 TLS를 확인하는 Web API 인증 필터를 보여줍니다.

public class RequireHttpsAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext.Request.RequestUri.Scheme != Uri.UriSchemeHttps)
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Forbidden)
            {
                ReasonPhrase = "HTTPS Required"
            };
        }
        else
        {
            base.OnAuthorization(actionContext);
        }
    }
}

TLS가 필요한 모든 Web API 작업에 이 필터를 추가합니다.

public class ValuesController : ApiController
{
    [RequireHttps]
    public HttpResponseMessage Get() { ... }
}

Azure Cache for Redis에 대한 통신이 TLS를 통해 이루어지는지 확인

제목 세부 정보
구성 요소 Azure Cache for Redis (아주어 캐시 포 레디스)
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 Azure Redis TLS 지원
단계 Redis 서버는 TLS를 기본으로 지원하지 않지만 Azure Cache for Redis는 지원합니다. Azure Cache for Redis에 연결하고 클라이언트가 StackExchange.Redis와 같은 TLS를 지원하는 경우 TLS를 사용해야 합니다. 기본적으로 비 TLS 포트는 새 Azure Cache for Redis 인스턴스에 대해 사용하지 않도록 설정됩니다. redis 클라이언트에 대한 TLS 지원에 대한 종속성이 없는 한 보안 기본값이 변경되지 않는지 확인합니다.

Redis는 신뢰할 수 있는 환경 내의 신뢰할 수 있는 클라이언트에서 액세스하도록 설계되었습니다. 즉, 일반적으로 Redis 인스턴스를 인터넷에 직접 노출하거나 일반적으로 신뢰할 수 없는 클라이언트가 Redis TCP 포트 또는 UNIX 소켓에 직접 액세스할 수 있는 환경에 노출하는 것은 좋지 않습니다.

보안 디바이스와 필드 게이트웨이 간의 통신

제목 세부 정보
구성 요소 IoT 필드 게이트웨이
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 해당 없음(N/A)
단계 IP 기반 디바이스의 경우 통신 프로토콜은 일반적으로 전송 중인 데이터를 보호하기 위해 SSL/TLS 채널에 캡슐화될 수 있습니다. SSL/TLS를 지원하지 않는 다른 프로토콜의 경우 전송 또는 메시지 계층에서 보안을 제공하는 프로토콜의 보안 버전이 있는지 조사합니다.

SSL/TLS를 사용하여 디바이스-클라우드 게이트웨이 통신 보호

제목 세부 정보
구성 요소 IoT 클라우드 게이트웨이
SDL 단계 빌드
적용 가능한 기술 일반
특성 해당 없음(N/A)
참조 통신 프로토콜 선택
단계 SSL/TLS를 사용하여 HTTP/AMQP 또는 MQTT 프로토콜을 보호합니다.