기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 커넥터 개발자를 위한 일반/사용자 지정 권한 부여 요구 사항
<a name="concepts-general-authorization-dev"></a>

일반 권한 부여를 사용하면 커넥터가 OAuth 2.0 사용자 토큰 대신 자격 증명(예: API 키, 토큰 또는 사용자 이름/암호 조합)을 사용할 수 있습니다. 계정 연결을 통해 사용자 수준 권한을 제공하는 OAuth 2.0과 달리 일반 권한 부여를 사용하면 단일 자격 증명 세트가 여러 최종 사용자에 걸쳐 디바이스를 제어할 수 있습니다.

**참고**  
이 설명서 전체에서 사용자 지정 권한 부여를 일반 권한 부여라고 합니다. 두 용어 모두 동일한 권한 부여 메커니즘을 설명합니다. 다음 섹션에서는 일관성을 위해 "일반 권한 부여"를 사용합니다.

이 섹션에서는 커넥터 AWS Lambda 함수에서 일반 권한 부여 지원을 구현하는 방법을 설명합니다. 기존 커넥터에 대한 일반 승인을 구성하는 고객인 경우 섹션을 참조하세요[일반/사용자 지정 권한 부여 요구 사항](concepts-general-authorization.md).

**Topics**
+ [일반 승인이란 무엇입니까?](#what-is-general-auth-dev)
+ [일반 권한 부여에서를 사용하는 방법 AWS Secrets Manager](#general-auth-secrets-manager-dev)
+ [일반 권한 부여 요청 형식](#general-auth-request-format)
+ [일반 권한 부여 워크플로](#general-auth-workflow-dev)
+ [GeneralAuthorization에 대한 Lambda 권한](#general-auth-lambda-permissions-dev)

## 일반 승인이란 무엇입니까?
<a name="what-is-general-auth-dev"></a>

일반 권한 부여는 커넥터가 고객 자격 증명을 사용하여 타사 플랫폼으로 권한을 부여할 수 있는 비 OAuth 권한 부여 메커니즘입니다. 일반 승인을 통해 관리형 통합은 자격 증명 관리를 커넥터에 위임하고 단일 자격 증명 세트는 여러 최종 사용자에 걸쳐 디바이스를 제어할 수 있습니다.

이는 디바이스 공급업체와 비즈니스 관계가 있고 개별 사용자 권한 부여 흐름 없이 대규모로 디바이스를 관리해야 하는 시나리오에 유용합니다.

### 일반 권한 부여를 사용해야 하는 경우
<a name="when-to-use-general-auth"></a>

다음과 같은 경우 커넥터에서 일반 승인 지원을 구현하는 것이 좋습니다.
+ 타사 플랫폼은 OAuth 2.0을 지원하지 않습니다.
+ 타사 플랫폼은에 상주할 수 있는 API 키 또는 자격 증명과 같은 사용자 지정 권한 부여 자료를 제공합니다. AWS Secrets Manager
+ 개별 사용자 권한 부여 흐름 없이 대규모 디바이스를 관리해야 함

**참고**  
커넥터는 두 권한 부여 유형을 병렬로 구현하여 다양한 권한 부여 프레임워크와의 호환성을 제공할 수 있습니다.

## 일반 권한 부여에서를 사용하는 방법 AWS Secrets Manager
<a name="general-auth-secrets-manager-dev"></a>

AWS Secrets Manager 는 API 키 및 토큰과 같은 민감한 자격 증명을 보호하는 보안 암호 스토리지 서비스입니다. 보안 암호는 AWS Key Management Service 키를 사용하여 암호화됩니다. 자세한 내용은 [AWS Secrets Manager 사용 설명서](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)를 참조하십시오.

일반 권한 부여의 경우 고객은 Secrets Manager에 권한 부여 자격 증명을 저장하고 C2C 커넥터에 이러한 보안 암호에 액세스할 수 있는 권한을 부여합니다. 관리형 통합은 커넥터를 호출할 때 요청 헤더에 Secrets Manager ARN 및 버전 ID를 제공합니다. 커넥터는 보안 암호 값을 검색하고 이를 사용하여 타사 플랫폼으로 권한을 부여합니다.

이 접근 방식을 사용하면 관리형 통합이 장기 자격 증명을 직접 처리하지 않습니다. 커넥터는 자격 증명 관리 및 토큰 생성을 완벽하게 제어하여 타사 플랫폼에서 지원하는 모든 권한 부여 메커니즘으로 솔루션을 확장할 수 있습니다.

**중요**  
관리형 통합은 고객의에 저장된 자격 증명에 액세스하거나 관리하지 않습니다 AWS Secrets Manager. 커넥터는 자격 증명 검색, 구문 분석 및 사용을 완벽하게 제어할 수 있습니다.

**중요**  
민감한 자격 증명이나 토큰을 로그에 기록하지 않는 것이 좋습니다. 그러나 로그에 저장되는 경우 CloudWatch Logs 데이터 보호 정책을 사용하여 로그의 토큰을 마스킹하는 것이 좋습니다. 자세한 내용은 [Help protect sensitive log data with masking](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html)을 참조하세요.

## 일반 권한 부여 요청 형식
<a name="general-auth-request-format"></a>

Managed Integrations가 일반 승인 계정 연결을 위해 커넥터를 호출하면 요청 헤더에 OAuth 토큰 대신 AWS Secrets Manager 참조가 포함됩니다. 요청 구조는 모든 커넥터 작업(`AWS.ActivateUser`, `AWS.DiscoverDevices`, `AWS.SendCommand`및 `AWS.DeactivateUser`)에서 일관됩니다.

**Example 예: 일반 권한 부여 요청**  

```
{
  "header": {
    "auth": {
      "secretsManager": {
        "arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-api-key-AbCdEf",
        "versionId": "a1b2c3d4-5678-90ab-cdef-1234567890ab"
      },
      "type": "GeneralAuthorization"
    }
  },
  "payload": {
    "operationName": "AWS.DiscoverDevices",
    "operationVersion": "1.0",
    "connectorId": "Your-Connector-Id",
    ...
  }
}
```

**Example 예: OAuth 2.0 요청(비교용)**  

```
{
  "header": {
    "auth": {
      "token": "ashriu32yr97feqy7afsaf",
      "type": "OAuth2.0"
    }
  },
  "payload": {
    "operationName": "AWS.DiscoverDevices",
    "operationVersion": "1.0",
    "connectorId": "Your-Connector-Id",
    ...
  }
}
```

**참고**  
커넥터는 두 요청 형식을 모두 처리해야 합니다. `auth.type` 필드를 확인하여 각 요청에 사용할 권한 부여 방법을 결정합니다.

## 일반 권한 부여 워크플로
<a name="general-auth-workflow-dev"></a>

커넥터가 일반 승인 요청을 받으면 다음 워크플로를 따릅니다.
+ **권한 부여 유형 확인** - 요청 헤더의 `auth.type` 필드를 확인하여 요청이 일반 권한을 사용하는지 확인합니다.
+ **Secrets Manager 참조 추출** - `auth.secretsManager` 객체에서 AWS Secrets Manager ARN 및 버전 ID 추출
+ **보안 암호 검색** - 제공된 ARN 및 버전 ID를 사용하여 API를 호출합니다 AWS Secrets Manager `GetSecretValue`.
+ **자격 증명 구문 분석** - 보안 암호 값을 구문 분석하여 권한 부여 자격 증명을 추출합니다(형식은 타사 플랫폼의 요구 사항에 따라 다름).
+ **토큰 생성(필요한 경우)** - 필요한 경우 자격 증명을 사용하여 액세스 토큰을 생성하거나 타사 플랫폼에 필요한 추가 권한 부여 단계를 수행합니다.
+ **API 호출 권한 부여** - 자격 증명 또는 생성된 토큰을 사용하여 타사 플랫폼에 대한 API 호출 권한 부여
+ **프로세스 작업** - 승인된 연결을 사용하여 커넥터 작업(`AWS.DiscoverDevices``AWS.SendCommand`, 등)을 처리합니다.

**참고**  
커넥터는 토큰 생성, 새로 고침, 오류 처리를 포함한 모든 자격 증명 관리를 담당합니다. 관리형 통합은 보안 암호에 대한 참조만 제공하며 자격 증명 자체는 관리하지 않습니다.

## GeneralAuthorization에 대한 Lambda 권한
<a name="general-auth-lambda-permissions-dev"></a>

커넥터 Lambda 실행 역할에는 고객의에서 보안 암호를 검색할 수 있는 권한이 있어야 합니다 AWS Secrets Manager. Lambda 실행 역할 정책에 다음 권한을 추가합니다.

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:*:*:secret:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "secretsmanager.*.amazonaws.com"
        }
      }
    }
  ]
}
```

**권한 설명**
+ `secretsmanager:GetSecretValue` - Lambda가 보안 암호 값을 검색하도록 허용
+ `kms:Decrypt` - 보안 암호는 AWS Key Management Service 키를 사용하여 암호화되므로 필요합니다.

**참고**  
예제 정책은 모든 보안 암호에 대한 액세스를 허용합니다. 프로덕션 환경에서는 커넥터에 필요한 보안 암호로만 `Resource` 필드를 제한해야 합니다. 그러나 고객이 자체 보안 암호를 생성하므로 와일드카드를 사용하거나 고객이 따라야 하는 이름 지정 규칙을 문서화해야 할 수 있습니다.

또한 고객은 Lambda에 보안 암호의 리소스 정책을 통해 특정 보안 암호에 액세스할 수 있는 권한을 부여합니다.