연결하다 Azure Database for MySQL 엑셀, 구글 시트, AI 및 REST로

여기서 TLS는 호스트 이름이 아니라 체크박스를 따릅니다.

Azure PostgreSQL 페이지의 내용을 그대로 복사하는 것은 잘못된 것이므로, 이 점을 명확히 밝히는 것이 중요합니다.

• SSL 사용은 기본적으로 활성화되어 있으며, SSL이 활성화된 동안 연결은 암호화됩니다. — 에이전트는 MySQL에 필요한 TLS 세션을 요청합니다.
• 이 기능을 끄면 에이전트가 암호화되지 않은 연결을 시도합니다. MySQL 경로의 어떤 내용도 호스트 이름을 기반으로 한 연결을 재정의하지 않으며, 바로 이 부분이 이 카드가 Azure PostgreSQL과 다른 점입니다.
• 그 이유는 단순한 실수가 아니라 구조적인 문제입니다. 에이전트는 TLS를 강제 적용하는 호스팅된 PostgreSQL 호스트 이름 목록을 테이블에 저장하는데, MySQL에는 이에 상응하는 기능이 없습니다. 체크박스가 바로 그 메커니즘의 핵심입니다.
• 암호화는 인증서 검증이 아닙니다. 에이전트는 TLS를 요구하지만 서버의 인증서 체인을 검증하지는 않으므로, TLS는 연결 상태를 도청으로부터 보호하는 수단일 뿐 연결의 정확성을 보장하는 것은 아닙니다.

유연한 서버와 사용자 이름 함정

Azure는 MySQL을 두 가지 형태로 제공하는데, 사용자 이름 형식에 대해 서로 다른 의견을 가지고 있습니다. 카드는 어느 쪽 편을 드는지 보여줍니다.

• 이 카드는 유연한 서버 환경에 맞게 설계되었습니다. 기본 포트는 3306이며 서버 이름은 .mysql.database.azure.com으로 끝납니다.
• 유연한 서버는 일반 사용자 이름을 사용합니다. 이전에 제공되었던 단일 서버 제품은 user@servername 형식을 사용했는데, 해당 형식을 붙여넣으면 Azure에서 인증 실패로 간주하여 나중에 거부하지 않도록 접미사를 삭제하라는 안내 메시지가 표시됩니다.
• 거기서 오류를 잡아내는 게 더 낫습니다. @servername 로그인 시도는 서버에서 일반적인 인증 오류로 처리되어, 잘못된 적도 없는 비밀번호를 재설정하라는 메시지가 뜨게 됩니다.
• 비밀번호 앞뒤에 공백이 있는 경우에도 문제가 발생합니다. 이는 클립보드에서 발생하는 오류이며, 일반적인 인증 오류로 간주됩니다.

개인 엔드포인트는 에이전트에 적합합니다.

에이전트가 발신만 하고 수신은 하지 않기 때문에 데이터베이스 서버를 노출하는 일반적인 이유는 적용되지 않습니다.

• 에이전트를 동일한 VNet 내의 VM에 설치하고 프라이빗 엔드포인트를 가리키도록 설정합니다. 공용 액세스는 비활성화된 상태로 유지할 수 있습니다.
• 추가해야 할 인바운드 방화벽 규칙도 없고, 관리해야 할 IP 허용 목록도 없으며, 귀사 네트워크와 당사 네트워크 사이에 VPN도 필요하지 않습니다. 에이전트가 외부 연결을 열어줍니다.
• 인증은 사용자 이름과 비밀번호로 이루어집니다. Microsoft Entra ID는 이 커넥터에 연결되어 있지 않으므로, 노출하려는 데이터에만 접근 권한이 부여된 MySQL 로그인 계정을 사용하십시오.
• 읽기 전용 사용자는 2분 정도 투자할 가치가 있습니다. 쿼리 스트림은 쓰기 작업을 수행하지 않지만, 이를 보장하는 가장 안전한 방법은 데이터베이스에서 직접 확인하는 것입니다.

-- 일반 MySQL, 읽기 전용, TLS 사용 SELECT c.name, COUNT(o.id) AS orders, SUM(o.amount) AS revenue FROM customers AS c JOIN orders AS o ON o.customer_id = c.id WHERE o.placed_at >= NOW() - INTERVAL 30 DAY GROUP BY c.name ORDER BY revenue DESC;