

# AWS Glue의 알려진 문제
<a name="glue-known-issues"></a>

다음은 AWS Glue에서 알려진 문제입니다.

**Topics**
+ [작업 간 데이터 액세스 방지](#cross-job-access)

## 작업 간 데이터 액세스 방지
<a name="cross-job-access"></a>

각각 별도의 AWS Glue Spark 클러스터에서 실행되는 AWS Glue Spark 작업 2개가 단일 AWS 계정에 있다고 가정하겠습니다. 두 작업은 AWS Glue 연결을 사용해 동일한 가상 프라이빗 클라우드(VPC)의 리소스에 액세스합니다. 이때 한쪽 클러스터에서 실행되는 작업은 다른 클러스터에서 실행되는 작업의 데이터에 액세스할 수 있어야 합니다.

다음 다이어그램은 이러한 상황을 예로 든 그림입니다.

![AWS Glue 작업 Cluster-1의 Job-1과 Cluster-2의 Job-2가 VPC에서 Subnet-1에 속하는 Amazon Redshift 인스턴스와 통신하고 있습니다. 데이터는 Amazon S3 Bucket-1 및 Bucket-2에서 Amazon Redshift로 전송 중입니다.](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/escalation-of-privs.png)


위 다이어그램을 보면 AWS Glue `Job-1`은 `Cluster-1`에서, 그리고 Job-2는 `Cluster-2`에서 실행 중입니다. 두 작업 모두 VPC의 `Subnet-1`에 속하면서 동일한 Amazon Redshift 인스턴스와 통신하고 있습니다. 이때 `Subnet-1`은 퍼블릭 서브넷 또는 프라이빗 서브넷이 될 수 있습니다.

`Job-1`은 Amazon Simple Storage Service(Amazon S3) `Bucket-1`의 데이터를 변환하여 Amazon Redshift에 작성하고 있습니다. `Job-2`는 `Bucket-2`의 데이터를 사용해 동일하게 실행하고 있습니다. `Job-1`은 AWS Identity and Access Management(IAM) 역할인 `Role-1`(그림에 보이지 않음)을 사용해 `Bucket-1`에 대한 액세스 권한을 얻습니다. `Job-2`는 `Role-2`(그림에 보이지 않음)를 사용해 `Bucket-2`에 대한 액세스 권한을 얻습니다.

두 작업은 서로 클러스터와 통신할 수 있는 네트워크 경로가 있기 때문에 각 데이터에 액세스할 수 있습니다. 예를 들어 `Job-2`는 `Bucket-1`의 데이터에 액세스할 수 있습니다. 위 다이어그램에서는 빨간색으로 표시된 선이 네트워크 경로입니다.

이러한 상황을 방지하려면 `Job-1`과 `Job-2`에 서로 다른 보안 구성을 연결하는 것이 좋습니다. 보안 구성을 연결하면 AWS Glue에서 생성되는 인증서를 통해 작업 간 데이터 액세스가 차단됩니다. 보안 구성은 *더미* 구성이 될 수 있습니다. 이 말은 Amazon S3 데이터, Amazon CloudWatch 데이터 또는 작업 북마크를 암호화하지 않고 보안 구성을 생성할 수 있다는 것을 의미합니다. 세 가지 암호화 옵션 모두 비활성화가 가능합니다.

보안 구성에 대한 자세한 내용은 [AWS Glue에서 작성한 데이터 암호화](encryption-security-configuration.md) 단원을 참조하십시오.

**보안 구성을 작업에 연결하려면**

1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)에서 AWS Glue 콘솔을 엽니다.

1. 해당 작업의 **Configure the job properties(작업 속성 구성)** 페이지에서 **Security configuration, script libraries, and job parameters(보안 구성, 스크립트 라이브러리 및 작업 파라미터)** 섹션을 확장합니다.

1. 목록에서 보안 구성을 선택합니다.