다음을 통해 공유

Azure Blob Storage에 대한 SFTP(SSH 파일 전송 프로토콜) 지원

  • 아티클

Blob Storage는 이제 SSH SFTP(파일 전송 프로토콜)를 지원합니다. 이 지원을 통해 SFTP 클라이언트를 사용하여 Blob Storage에 안전하게 연결할 수 있으므로 파일 액세스, 파일 전송 및 파일 관리에 SFTP를 사용할 수 있습니다.

여기에 대해 자세히 설명하는 동영상이 있습니다.

Azure는 Azure Blob service REST API, Azure SDK 및 AzCopy와 같은 도구를 사용하여 Blob Storage 계정에 보안 데이터 전송을 허용합니다. 그러나 레거시 워크로드는 SFTP와 같은 기존의 파일 전송 프로토콜을 사용하는 경우가 많습니다. REST API 및 Azure SDK를 사용하기 위해 사용자 지정 응용 프로그램을 업데이트할 수 있지만, 중요한 코드를 통해서만 가능합니다.

이 기능이 출시되기 전에 SFTP를 사용하여 Azure Blob Storage로 데이터를 전송하려면 타사 제품을 구입하거나 자체 솔루션을 오케스트레이션해야 합니다. 사용자 지정 솔루션의 경우 Azure에서 VM(가상 머신)을 만들어 SFTP 서버를 호스트한 다음, 복잡한 아키텍처를 업데이트, 패치, 관리, 크기 조정 및 유지 관리해야 합니다.

이제 Azure Blob Storage에 대한 SFTP 지원을 통해 한 번 클릭으로 Blob Storage 계정에 대한 SFTP 지원을 사용하도록 설정할 수 있습니다. 그런 다음, 22 포트를 통해 SFTP를 사용하여 스토리지 계정에 연결하도록 인증에 대한 로컬 사용자 ID를 설정할 수 있습니다.

이 문서에서는 Azure Blob Storage의 SFTP 지원에 대해 설명합니다. 스토리지 계정에 SFTP를 사용하도록 설정하는 방법에 대한 자세한 내용은 SFTP(SSH 파일 전송 프로토콜)을 사용하여 Azure Blob Storage에 연결을 참조하세요.

참고 항목

SFTP는 플랫폼 수준 서비스이므로 계정 옵션이 비활성화된 경우에도 포트 22가 열립니다. SFTP 액세스가 구성되지 않은 경우 모든 요청은 서비스에서 연결이 끊어집니다.

SFTP 및 계층 구조 네임스페이스

SFTP 지원을 사용하려면 계층 구조 네임스페이스를 사용하도록 설정해야 합니다. 계층 구조 네임스페이스는 컴퓨터의 파일 시스템을 구성하는 것과 동일한 방식으로 개체(파일)를 디렉터리 및 하위 디렉터리의 계층 구조로 구성합니다. 계층 구조 네임스페이스는 선형으로 확장되며 데이터 용량 또는 성능을 저하시키지 않습니다.

계층 구조 네임스페이스는 다양한 프로토콜을 지원합니다. SFTP는 이러한 사용 가능한 프로토콜 중 하나입니다. 다음 이미지는 여러 프로토콜 및 REST API를 통한 스토리지 액세스를 보여 줍니다. 보다 쉽게 ​​읽을 수 있도록, 이 이미지에서는 Azure Data Lake Storage REST API를 지칭하기 위해 REST라는 용어를 사용합니다.

계층 구조 네임스페이스

SFTP 권한 모델

SFTP 클라이언트는 Microsoft Entra ID를 사용하여 권한 부여할 수 없습니다. 대신 SFTP는 로컬 사용자라는 새로운 형태의 ID 관리를 활용합니다.

로컬 사용자는 인증을 위해 암호 또는 SSH(Secure Shell) 프라이빗 키 자격 증명을 사용해야 합니다. 스토리지 계정에는 최대 8,000명의 로컬 사용자를 보유할 수 있습니다.

액세스 권한을 설정하려면 로컬 사용자를 만들고 인증 방법을 선택합니다. 그런 다음 계정의 각 컨테이너에 대해 해당 사용자에게 부여할 액세스 수준을 지정할 수 있습니다.

주의

로컬 사용자는 RBAC(역할 기반 액세스 제어) 및 ABAC(특성 기반 액세스 제어)와 같은 다른 Azure Storage 권한 모델과 상호 운용되지 않습니다. ACL(액세스 제어 목록)은 미리 보기 수준에서 로컬 사용자에 대해 지원됩니다.

예를 들어 Jeff에게는 con1 컨테이너에 저장된 foo.txt 파일의 Microsoft Entra ID를 통한 읽기 전용 권한(RBAC 또는 ABAC를 통해 제어할 수 있음)이 있습니다. Jeff가 NFS(루트/슈퍼 사용자로 탑재되지 않은 경우), Blob REST 또는 Data Lake Storage REST를 통해 스토리지 계정에 액세스하는 경우 이러한 권한이 적용됩니다. 그러나 Jeff에게 con1 컨테이너의 데이터에 대한 삭제 권한이 있는 로컬 사용자 ID도 있는 경우 로컬 사용자 ID를 사용하여 SFTP를 통해 foo.txt를 삭제할 수 있습니다.

SFTP 지원을 사용하도록 설정해도 다른 형식의 클라이언트가 Microsoft Entra ID를 사용하는 것을 방지할 수는 없습니다. Azure Portal, Azure CLI, Azure PowerShell 명령, AzCopy, Azure SDK 및 Azure REST API를 사용하여 Blob Storage에 액세스하는 사용자의 경우 전체 범위의 Azure Blob Storage 보안 설정을 계속 사용하여 액세스 권한을 부여할 수 있습니다. 자세한 정보는 Azure Data Lake Storage의 액세스 제어 모델을 참조하세요.

인증 방법

암호 또는 SSH(Secure Shell) 공용-프라이빗 키 쌍을 사용하여 SFTP를 통해 연결하는 로컬 사용자를 인증할 수 있습니다. 두 가지 인증 형식을 모두 구성하고 연결하는 로컬 사용자가 사용할 인증을 선택하도록 할 수 있습니다. 그러나 성공적인 인증을 위해 유효한 암호 및 유효한 공개-프라이빗 키 쌍 모두에 필요한 다단계 인증은 지원되지 않습니다.

암호

사용자 지정 암호는 설정할 수 없습니다. 대신 Azure에서 자동으로 생성합니다. 암호 인증을 선택하면 로컬 사용자 구성을 완료한 후에 암호가 제공됩니다. 해당 암호를 복사하고 나중에 찾을 수 있는 위치에 저장해야 합니다. Azure에서 해당 암호를 다시 검색할 수는 없습니다. 암호를 잊어버린 경우 새 암호를 생성해야 합니다. 보안상의 이유로 암호는 직접 설정할 수 없습니다.

SSH 키 쌍

공개-프라이빗 키 쌍은 SSH(Secure Shell)에 대한 가장 일반적인 인증 형식입니다. 프라이빗 키는 비밀이며 로컬 사용자만 알고 있어야 합니다. 공개 키는 Azure에 저장됩니다. SSH 클라이언트가 로컬 사용자 ID를 사용하여 스토리지 계정에 연결하면 공개 키와 서명이 포함된 메시지를 보냅니다. Azure는 메시지의 유효성을 검사하고 스토리지 계정에서 사용자와 키를 인식하는지 확인합니다. 자세한 내용은 SSH 및 키 개요를 참조하세요.

프라이빗-공개 키 쌍을 사용하여 인증하도록 선택하는 경우 하나의 쌍을 생성하거나, Azure에 이미 저장된 키 쌍을 사용하거나, Azure에 기존의 공개-프라이빗 키 쌍을 제공할 수 있습니다. 로컬 사용자당 최대 10개의 공개 키를 가질 수 있습니다.

컨테이너 권한

컨테이너 수준 권한의 경우 액세스 권한을 부여할 컨테이너와 제공하려는 액세스 수준(읽기, 쓰기, 목록, 삭제, 만들기, 소유권 수정 및 권한 수정)을 선택할 수 있습니다. 이러한 사용 권한은 컨테이너의 모든 디렉터리 및 하위 디렉터리에 적용됩니다. 각 로컬 사용자에게 100개의 컨테이너에 대한 액세스 권한을 부여할 수 있습니다. 로컬 사용자를 만든 후 컨테이너 사용 권한을 업데이트할 수도 있습니다. 다음 테이블에서는 각 사용 권한에 대해 자세히 설명합니다.

Permission 기호 설명
읽음 r
  • 파일 콘텐츠 읽기
    		•
    쓰기 w
  • 파일 업로드
  • 디렉터리 만들기
  • 업로드 디렉터리
    		•
    List l
  • 컨테이너 내 콘텐츠 나열
  • 디렉터리 내 콘텐츠 나열
    		•
    삭제 d
  • 파일/디렉터리 삭제
    		•
    만들기 c
  • 파일 업로드(파일이 없는 경우)
  • 디렉터리 만들기(디렉터리가 없는 경우)
    		•
    소유권 수정 o
  • 파일이나 디렉터리의 담당 사용자 또는 담당 그룹 변경
    		•
    권한 수정 p
  • 파일 또는 디렉터리의 ACL 변경
    		•

    하위 디렉터리의 Blob에 대한 쓰기 작업을 수행할 때 디렉터리를 열고 Blob 속성에 액세스하려면 읽기 권한이 필요합니다.

    ACL(액세스 제어 목록)

    Important

    이 기능은 현재 미리 보기로 제공되고 있습니다. 베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.

    ACL을 사용하면 특정 디렉터리 또는 파일에 대한 쓰기 액세스와 같은 "세분화된" 액세스 권한을 부여할 수 있습니다. ACL에 대해 자세히 알아보려면 Azure Data Lake Storage의 ACL(액세스 제어 목록)을 참조하세요.

    ACL을 사용하여 로컬 사용자에게 권한을 부여하려면 먼저 해당 로컬 사용자에 대해 ACL 권한 부여를 사용하도록 설정해야 합니다. 컨테이너에 권한 부여를 참조하세요.

    참고 항목

    ACL은 다양한 형식의 ID에 대한 권한 수준을 정의할 수 있지만 담당 사용자, 담당 그룹 및 기타 모든 사용자 ID만 사용하여 로컬 사용자를 권한 부여할 수 있습니다. 명명된 사용자 및 명명된 그룹은 아직 로컬 사용자 권한 부여를 지원하지 않습니다.

    다음 표에서는 ACL 권한 부여에 사용되는 로컬 사용자의 속성을 설명합니다.

    속성 설명
    UserId
  • 스토리지 계정 내 로컬 사용자의 고유 식별자
  • 로컬 사용자를 만들 때 기본적으로 생성됨
  • 파일/디렉터리에서 소유 사용자를 설정하는 데 사용됨
    		•
    GroupId
  • 로컬 사용자 그룹의 식별자
  • 파일/디렉터리의 소유 그룹을 설정하는 데 사용됨
    		•
    AllowAclAuthorization
  • 이 로컬 사용자의 요청에 ACL 권한 부여 허용
    		•

    ACL 권한 평가 방법

    ACL은 로컬 사용자에게 작업을 수행하는 데 필요한 컨테이너 권한이 없는 경우에만 평가됩니다. 시스템에서 액세스 권한을 평가하는 방식으로 인해 ACL을 사용하여 컨테이너 수준 권한으로 이미 부여된 액세스를 제한할 수 없습니다. 이는 시스템이 컨테이너 권한을 먼저 평가하고 해당 권한이 충분한 액세스 권한을 부여하는 경우 ACL이 무시되기 때문입니다.

    Important

    로컬 사용자에게 파일에 대한 읽기 또는 쓰기 권한을 부여하려면 해당 로컬 사용자에게 컨테이너의 루트 폴더와 파일로 연결되는 폴더 계층 구조의 각 폴더에 대한 실행 권한을 부여해야 합니다. 로컬 사용자가 담당 사용자 또는 담당 그룹인 경우 담당 사용자 또는 담당 그룹에 실행 권한을 적용할 수 있습니다. 그렇지 않으면 다른 모든 사용자에게 실행 권한을 적용해야 합니다.

    SFTP 클라이언트로 ACL 수정

    ACL 권한은 지원되는 Azure 도구 또는 SDK를 사용하여 수정할 수 있지만 로컬 사용자도 수정할 수 있습니다. 로컬 사용자가 ACL 권한을 수정할 수 있게 하려면 먼저 로컬 사용자에게 Modify Permissions 권한을 부여해야 합니다. 컨테이너에 권한 부여를 참조하세요.

    로컬 사용자는 담당 사용자, 담당 그룹 및 ACL의 다른 모든 사용자의 권한 수준만 변경할 수 있습니다. 명명된 사용자, 명명된 그룹 및 명명된 보안 주체에 대한 ACL 항목을 추가하거나 수정하는 것은 아직 지원되지 않습니다.

    로컬 사용자는 담당 사용자 및 담당 그룹의 ID를 변경할 수도 있습니다. 실제로 로컬 사용자만 담당 사용자 또는 담당 그룹의 ID를 로컬 사용자 ID로 변경할 수 있습니다. 아직 Azure 도구 또는 SDK를 사용하여 ACL에서 로컬 사용자 ID를 참조할 수 없습니다. 디렉터리나 Blob의 담당 사용자나 담당 그룹을 변경하려면 로컬 사용자에게 Modify Ownership 권한이 부여되어야 합니다.

    예를 보려면 파일 또는 디렉터리의 ACL 수정을 참조하세요.

    홈 디렉터리

    권한을 구성할 때 로컬 사용자에 대한 홈 디렉터리를 설정하는 옵션이 있습니다. SFTP 연결 요청에 다른 컨테이너가 지정되지 않은 경우, 홈 디렉터리는 기본적으로 사용자가 연결하는 디렉터리입니다. 예를 들어 SSH 열기를 사용하여 만든 다음 요청을 고려합니다. 이 요청은 sftp 명령의 일부로 컨테이너 또는 디렉터리 이름을 지정하지 않습니다.

    sftp myaccount.myusername@myaccount.blob.core.windows.net
put logfile.txt

    사용자의 홈 디렉터리를 mycontainer/mydirectory로 설정하면 해당 디렉터리에 연결됩니다. 그런 다음 logfile.txt 파일이 mycontainer/mydirectory에 업로드됩니다. 홈 디렉터리를 설정하지 않으면 연결 시도가 실패합니다. 대신, 연결 사용자는 요청과 함께 컨테이너를 지정한 다음 SFTP 명령을 사용하여 파일을 업로드하기 전에 대상 디렉터리로 이동합니다. 다음 예제에서는 이러한 방법을 보여줍니다.

    sftp myaccount.mycontainer.myusername@myaccount.blob.core.windows.net
cd mydirectory
put logfile.txt

    참고 항목

    홈 디렉터리는 연결하는 로컬 사용자가 있는 초기 디렉터리일 뿐입니다. 로컬 사용자는 적절한 컨테이너 권한이 있는 경우 연결된 컨테이너의 다른 경로로 이동할 수 있습니다.

    지원되는 알고리즘

    다양한 SFTP 클라이언트를 사용하여 안전하게 연결한 다음 파일을 전송할 수 있습니다. 연결 클라이언트는 아래 표에 지정된 알고리즘을 사용해야 합니다.

    Type 알고리즘
    호스트 키 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    키 교환 ecdh-sha2-nistp384
    ecdh-sha2-nistp256
    diffie-hellman-group14-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group-exchange-sha256
    암호/암호화 aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    무결성/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    공개 키 ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    1 호스트 키는 여기에 게시됩니다. 2 RSA 키의 길이는 2,048비트 이상이어야 합니다.

    Azure Blob Storage에 대한 SFTP 지원은 현재 보안 고려 사항에 따라 암호화 알고리즘 지원을 제한합니다. 고객은 Microsoft SDL(보안 개발 수명 주기) 승인 알고리즘을 사용하여 데이터에 안전하게 액세스할 것을 강력히 권장합니다.

    현재 Microsoft Security SDL에 따라 ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1, hmac-sha1-96을 지원할 계획이 없습니다. 알고리즘 지원은 향후 변경될 수 있습니다.

    SFTP를 사용하여 연결

    시작하려면 SFTP 지원을 사용하도록 설정하고, 로컬 사용자를 만들고, 해당 로컬 사용자에 대한 권한을 할당합니다. 그런 다음, 모든 SFTP 클라이언트를 사용하여 안전하게 연결한 다음, 파일을 전송할 수 있습니다. 단계별 지침은 SFTP(SSH 파일 전송 프로토콜)를 사용하여 Azure Blob Storage에 연결을 참조하세요.

    네트워킹 고려 사항

    SFTP는 플랫폼 수준 서비스이므로 계정 옵션이 비활성화된 경우에도 포트 22가 열립니다. SFTP 액세스가 구성되지 않은 경우 모든 요청은 서비스 연결 끊김을 받습니다. SFTP를 사용하는 경우 방화벽, 가상 네트워크 또는 프라이빗 엔드포인트의 구성을 통해 공용 액세스를 제한할 수 있습니다. 이러한 설정은 애플리케이션 계층에서 적용됩니다. 즉, SFTP와 관련이 없으며 모든 Azure Storage 엔드포인트에 대한 연결에 영향을 줍니다. 방화벽 및 네트워크 구성에 대한 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.

    참고 항목

    프로토콜 계층에서 TLS 지원을 확인하려는 감사 도구는 스토리지 계정 엔드포인트에 대해 직접 실행할 때 필요한 최소 버전 외에 TLS 버전을 반환할 수 있습니다. 자세한 내용은 스토리지 계정에 대한 요청에 대해 필요한 최소 버전의 TLS(전송 계층 보안) 적용을 참조하세요.

    지원되는 알려진 클라이언트

    다음 클라이언트는 Azure Blob Storage용 SFTP와 호환되는 알고리즘을 지원합니다. 연결에 문제가 있는 경우 Azure Blob Storage에 대한 SSH 파일 전송 프로토콜(SFTP) 지원의 제한 사항 및 알려진 이슈를 참조하세요. 이 목록은 완전하지 않으며 시간이 지남에 따라 변경될 수 있습니다.

    • AIX1
    • AsyncSSH 2.1.0+
    • Axway
    • curl 7.85.0+
    • Cyberduck 7.8.2+
    • edtFTPjPRO 7.0.0+
    • FileZilla 3.53.0+
    • Five9
    • JSCH 0.1.54+
    • libssh 0.9.5+
    • MobaXterm v21.3
    • Maverick Legacy 1.7.15+
    • Moveit 12.7
    • Mule 2.1.2+
    • OpenSSH 7.4+
    • paramiko 2.8.1+
    • phpseclib 1.0.13+
    • PuTTY 0.74+
    • QualysML 12.3.41.1+
    • RebexSSH 5.0.7119.0+
    • Ruckus 6.1.2 이상
    • Salesforce
    • ssh2js 0.1.20+
    • sshj 0.27.0+
    • SSH.NET 2020.0.0+
    • WinSCP 5.10+
    • Workday
    • XFB.Gateway

    1AllowPKCS12KeystoreAutoOpen 옵션을 no로 설정해야 합니다.

    제한 사항 및 알려진 문제

    Azure Blob Storage에 대한 SFTP 지원의 전체 제한 사항 및 문제 목록은 제한 사항 및 알려진 문제 문서를 참조하세요.

    가격 책정 및 대금 청구

    SFTP를 사용하도록 설정하려면 시간당 비용이 발생합니다. 최신 가격 책정 정보는 Azure Blob Storage 가격 책정을 참조하세요.

    팁

    수동 요금을 방지하려면 SFTP를 능동적으로 사용하여 데이터를 전송하는 경우에만 SFTP를 사용하도록 설정하는 것이 좋습니다. SFTP 지원을 사용하도록 설정했다가 사용하지 않도록 설정하는 방법에 대한 지침은 SFTP(SSH 파일 전송 프로토콜)를 사용하여 Azure Blob Storage에 연결을 참조하세요.

    기본 스토리지 계정에 대한 트랜잭션, 스토리지 및 네트워킹 가격이 적용됩니다. 모든 SFTP 트랜잭션은 스토리지 계정의 읽기, 쓰기 또는 기타 트랜잭션으로 변환됩니다. 여기에는 모든 SFTP 명령과 API 호출이 포함됩니다. 자세한 내용은 Azure Blob Storage에 대한 전체 청구 모델 이해를 참조하세요.

    관련 콘텐츠