분리형 웹 앱

참고: 분리형 웹 앱의 초기 출시와 이를 필요로 하는 모든 신뢰도 높은 API는 Chrome Enterprise 관리 ChromeOS 기기 및 일부 개발 파트너에게만 제공됩니다. 향후 더 많은 파트너와 관리되지 않는 교차 플랫폼 기기로 확대할 예정입니다.

웹은 정말로 고유한 애플리케이션 플랫폼입니다. 이 플랫폼을 기반으로 빌드된 앱은 코드 변경이나 컴파일 없이 모든 운영체제에서 즉시 액세스할 수 있습니다. 사용자가 앱에 접속할 때마다 항상 최신 버전이 표시됩니다. 설치 가능하고 오프라인으로 작동하며 기능이 매우 다양하고 링크 하나로 쉽게 공유할 수 있습니다. 웹 애플리케이션을 빌드하면 어디서나 작동합니다.

웹은 기본적으로 안전하고 보안한 것을 목표로 하므로 보안 모델은 매우 보수적이어야 합니다. 추가된 새로운 기능은 일반 사용자가 URL을 통해 우연히 발견해도 안전해야 합니다. 이 보안 모델을 드라이브 바이 웹이라고 합니다. 이는 많은 애플리케이션에 적합하며 콘텐츠 보안 정책 및 교차 출처 격리를 사용하여 더 안전하게 만들 수 있지만 모든 사용 사례에 적합하지는 않습니다. 개발자에게 필요한 직접 소켓, 제어된 프레임과 같은 매우 중요하고 강력한 API는 웹에서 안전하게 만들 수 없습니다.

이러한 애플리케이션의 경우 현재 웹에서 빌드하는 옵션이 없습니다. 다른 사용자의 경우 웹의 보안 모델이 충분히 보수적이지 않을 수 있습니다. 서버가 신뢰할 수 있다는 가정을 공유하지 않고 대신 개별적으로 버전이 지정되고 서명된 독립형 애플리케이션을 선호할 수 있습니다. 신뢰도가 높은 새로운 보안 모델이 필요합니다. 분리형 웹 앱 (IWA)은 이러한 개발자를 지원하기 위해 기존 웹 플랫폼을 기반으로 빌드된 격리되고 번들로 제공되며 버전이 지정되고 서명되고 신뢰할 수 있는 애플리케이션 모델을 제공합니다.

웹의 신뢰 스펙트럼

웹의 보안과 기능을 스펙트럼으로 생각할 수 있습니다.

왼쪽의 드라이브 바이 웹은 액세스 가능성이 가장 높아야 하므로 신뢰 보안 모델이 가장 낮으며 따라서 사용자 시스템에 대한 액세스 권한이 가장 적습니다. 브라우저에 설치된 웹 앱은 중간 정도의 신뢰를 얻으며 사용자의 시스템에 약간 더 깊이 통합될 수 있습니다. 일반적으로 사용자는 드라이브에서 제공하는 웹 버전의 앱과 브라우저에 설치된 버전을 문제없이 전환할 수 있습니다.

다음은 신뢰도가 높은 분리형 웹 애플리케이션입니다.

네이티브 앱과 더 유사하게 작동하고 느껴지며 심층 시스템 통합 및 강력한 기능에 액세스할 수 있습니다. 사용자는 이 두 가지와 드라이브 바이 웹 간에 전환할 수 없습니다. 이 수준의 보안 또는 이러한 기능이 필요한 경우 되돌릴 수 없습니다.

이 스펙트럼에서 목표로 삼을 위치를 결정할 때는 프로그레시브 웹 앱과 같이 가능한 가장 낮은 신뢰 수준의 보안 모델을 기본값으로 설정하세요. 이렇게 하면 도달범위가 가장 넓어지고, 직접 관리해야 하는 보안 문제가 가장 적으며, 개발자와 사용자에게 가장 유연합니다.

뛰어난 보안 설계

분리형 웹 앱은 웹 애플리케이션에 높은 신뢰도의 보안 모델을 제공합니다. 이를 사용 설정하려면 웹에서 신뢰에 관해 가정하는 몇 가지 사항을 다시 생각해 봐야 합니다. 서버와 DNS 같은 핵심 웹 빌딩 블록을 더 이상 명시적으로 신뢰할 수 없습니다. 네이티브 앱과 더 관련성이 높은 것으로 보이는 공격 벡터가 갑자기 중요해집니다. 따라서 IWA에서 제공하는 새로운 신뢰도 높은 보안 모델에 액세스하려면 웹 앱을 패키징하고, 격리하고, 잠가야 합니다.

패키징됨

분리형 웹 앱의 페이지와 애셋은 라이브 서버에서 제공하거나 일반 웹 애플리케이션처럼 네트워크를 통해 가져올 수 없습니다. 대신 새로운 신뢰도 높은 보안 모델에 액세스하려면 웹 앱이 실행에 필요한 모든 리소스를 서명된 WebBundle로 패키징해야 합니다. 서명된 웹 번들은 사이트를 실행하는 데 필요한 모든 리소스를 가져와 .swbn 파일로 함께 패키징하고 무결성 블록과 연결합니다. 이를 통해 웹 앱을 전체적으로 안전하게 다운로드하고 오프라인 상태에서도 공유하거나 설치할 수 있습니다.

하지만 TLS 키를 사용하려면 인터넷 연결이 필요하므로 사이트 코드의 진위성을 확인하는 데 문제가 있습니다. TLS 키 대신 IWA는 오프라인으로 안전하게 보관할 수 있는 키로 서명됩니다. 다행히도 모든 프로덕션 파일을 폴더에 모을 수 있다면 크게 수정하지 않고도 IWA로 전환할 수 있습니다.

경고: IWA는 설계상 일부 사이트 아키텍처를 제외합니다. 사이트는 오프라인 상태에서 각 페이지를 제공할 수 있어야 합니다. 즉, 서버 측 렌더링된 페이지는 포함할 수 없습니다. 정적으로 생성된 사이트 또는 클라이언트 측에서 렌더링된 사이트를 기본 아키텍처로 고려해야 합니다.

서명 키 생성

서명 키는 Ed25519 또는 ECDSA P-256 키 쌍으로, 비공개 키는 번들에 서명하는 데 사용되고 공개 키는 번들을 확인하는 데 사용됩니다. OpenSSL을 사용하여 Ed25519 또는 ECDSA P-256 키를 생성하고 암호화할 수 있습니다.

# Generate an unencrypted Ed25519 key
openssl genpkey -algorithm Ed25519 -out private_key.pem

# or generate an unencrypted ECDSA P-256 key
openssl ecparam -name prime256v1 -genkey -noout -out private_key.pem

# Encrypt the generated key. This will ask for a passphrase, make sure to use a strong one
openssl pkcs8 -in private_key.pem -topk8 -out encrypted_key.pem

# Delete the unencrypted key
rm private_key.pem

도움말: Mac을 사용하는 경우 openssl version을 실행하세요. LibreSSL이라고 표시되면 OpenSSL로 전환해야 합니다. brew install openssl를 실행하고 이 안내에 따라 기본값을 재정의하도록 연결하여 Homebrew를 사용하여 설치합니다.

서명 키에는 보조 목적도 있습니다. 도메인은 서버와 같이 제어권이 손실될 수 있으므로 설치된 IWA를 식별하는 데 사용할 수 없습니다. 대신 IWA는 서명의 일부이며 비공개 키에 연결된 번들의 공개 키로 식별됩니다. 이는 드라이브 바이 웹 작동 방식에 대한 중요한 변경사항이므로 HTTPS 대신 IWA는 새로운 스키마인 isolated-app://도 사용합니다.

경고: IWA의 ID는 서명에 사용된 비공개 키와 연결되어 있으므로 만드는 IWA마다 다른 서명 키가 필요합니다. 또한 동일한 앱에 서로 다른 서명 키로 서명하면 서로 다른 앱으로 간주되므로 원활한 업데이트 환경을 제공하는 데 영향을 미칩니다.

앱 번들링

서명 키를 사용할 수 있게 되었으므로 이제 웹 앱을 번들로 묶을 차례입니다. 이렇게 하려면 공식 NodeJS 패키지를 사용하여 IWA를 번들로 묶은 다음 서명하면 됩니다 (Go 명령줄 도구도 사용 가능). 먼저 wbn 패키지를 사용하여 모든 IWA의 프로덕션 파일이 포함된 폴더 (여기서는 dist)를 가리켜 서명되지 않은 번들로 래핑합니다.

npx wbn --dir dist

참고: npx은 NPM 명령어 (NPM 7 기준)이며, 여기서는 패키지를 전역으로 설치하거나 프로젝트의 종속 항목으로 설치하지 않고도 패키지를 실행하는 편리한 방법으로 사용됩니다. 항상 최신 버전의 패키지를 사용하려고 시도합니다. 빌드의 일관성이 필요한 경우 대신 이러한 패키지를 프로젝트의 개발 종속 항목으로 설치하고 npm 스크립트에서 실행해야 합니다.

그러면 해당 디렉터리의 서명되지 않은 웹 번들이 out.wbn.에 생성됩니다. 생성되면 이전에 만든 암호화된 Ed25519 또는 ECDSA P-256 키를 사용하여 wbn-sign으로 서명합니다.

npx wbn-sign -i out.wbn -k encrypted_key.pem -o signed.swbn

도움말: 이렇게 하면 키를 암호화하는 데 사용된 비밀번호를 입력하라는 메시지가 표시됩니다. WEB_BUNDLE_SIGNING_PASSPHRASE 환경 변수를 설정하여 비밀번호를 자동으로 전달할 수 있습니다.

그러면 signed.swbn라는 서명되지 않은 웹 번들에서 서명된 웹 번들이 생성됩니다. 서명되면 도구는 웹 번들 ID와 분리형 웹 앱 출처도 출력합니다. 분리형 웹 앱 출처는 브라우저에서 IWA를 식별하는 방법입니다.

Web Bundle ID: ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic
Isolated Web App Origin: isolated-app://ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic/

참고: IWA는 이 출처로 식별되지만 PWA와 마찬가지로 주소 표시줄 없이 자체 창에서 열리므로 사용자가 이를 볼 가능성은 거의 없습니다.

Webpack, Rollup 또는 플러그인을 지원하는 도구 (예: Vite)를 사용하는 경우 이러한 패키지를 직접 호출하는 대신 이러한 패키지를 래핑하는 번들러 플러그인(Webpack, Rollup) 중 하나를 사용할 수 있습니다. 이렇게 하면 서명된 번들이 빌드의 출력으로 생성됩니다.

도움말: 이러한 플러그인은 개발 파이프라인이 아닌 프로덕션 빌드 파이프라인의 일부로만 포함하면 됩니다.

앱 테스트

Chrome의 내장 IWA 개발자 프록시를 통해 개발 서버를 실행하거나 번들로 제공되는 IWA를 설치하는 두 가지 방법 중 하나로 IWA를 테스트할 수 있습니다. 이렇게 하려면 Chrome 또는 ChromeOS 120 이상을 사용하고, IWA 플래그를 사용 설정하고, Chrome의 웹 앱 내부를 통해 앱을 설치해야 합니다.

1. chrome://flags/#enable-isolated-web-app-dev-mode 플래그 사용 설정
2. 에서 Chrome의 웹 앱 내부 페이지로 이동하여 IWA를 테스트합니다.chrome://web-app-internals

웹 앱 내부 페이지에서 Install IWA with Dev Mode Proxy 또는 Install IWA from Signed Web Bundle 중 하나를 선택할 수 있습니다.

개발자 모드 프록시를 통해 설치하는 경우 로컬 개발 서버에서 실행되는 사이트를 포함한 모든 URL을 번들로 묶지 않고 IWA로 설치할 수 있습니다. 단, 다른 IWA 설치 요구사항을 충족해야 합니다. 설치가 완료되면 해당 URL의 IWA가 올바른 보안 정책과 제한이 적용되고 IWA 전용 API에 대한 액세스 권한이 있는 시스템에 추가됩니다. 무작위 식별자가 할당됩니다. 이 모드에서는 애플리케이션을 디버그하는 데 도움이 되는 Chrome 개발자 도구도 사용할 수 있습니다. 서명된 웹 번들에서 설치하면 서명된 번들 IWA를 업로드하며 최종 사용자가 다운로드한 것처럼 설치됩니다.

웹 앱 내부 페이지에서 개발자 모드 프록시를 통해 또는 서명된 웹 번들에서 설치된 애플리케이션의 업데이트 확인을 강제 실행하여 업데이트 프로세스를 테스트할 수도 있습니다.

격리됨

신뢰는 분리형 웹 앱의 핵심입니다. 이는 실행 방식에서 시작됩니다. 사용자는 앱이 브라우저에서 실행되는지 아니면 독립형 창에서 실행되는지에 따라 앱이 할 수 있고 해야 하는 일에 대해 서로 다른 사고방식을 가지고 있으며, 일반적으로 독립형 앱이 더 많은 액세스 권한을 가지고 더 강력하다고 생각합니다. IWA는 신뢰도가 높은 API에 액세스할 수 있으므로 이 정신 모델에 맞게 독립형 창에서 실행해야 합니다. 이렇게 하면 브라우저와 시각적으로 구분됩니다. 하지만 시각적 분리 이상의 기능을 제공합니다.

분리형 웹 앱은 브라우저 내 웹사이트와 다른 프로토콜(isolated-app 대 http 또는 https)에서 실행됩니다. 즉, 동일 출처 정책 덕분에 동일한 회사에서 빌드한 경우에도 각 IWA는 브라우저 내에서 실행되는 웹사이트와 완전히 분리됩니다. IWA 스토리지는 서로 분리되어 있습니다. 이를 통해 교차 출처 콘텐츠가 서로 다른 IWA 간에 또는 IWA와 사용자의 일반 탐색 컨텍스트 간에 유출되지 않습니다.

하지만 IWA가 설치 후 임의의 코드를 다운로드하고 실행할 수 있다면 사이트의 코드를 격리하거나 번들로 묶고 서명하는 것은 신뢰를 구축하는 데 유용하지 않습니다. 콘텐츠를 위해 IWA가 다른 사이트에 연결할 수 있도록 하면서도 이를 보장하기 위해 IWA는 엄격한 콘텐츠 보안 정책을 적용합니다.

• 번들의 JavaScript만 허용하지만 소스에 관계없이 Wasm 실행은 허용합니다. (script-src)
• JavaScript가 보안이 적용된 비로컬 호스트 교차 출처 도메인에서 가져오고, WebSocket 및 WebTransport 엔드포인트와 blob 및 data URL(connect-src)에 연결할 수 있도록 허용합니다.
• DOM 조작 함수를 사용할 수 있는 방법을 규제하여 DOM 교차 사이트 스크립트 삽입 (XSS) 공격을 방지합니다(require-trusted-types-for).
• 모든 HTTPS 도메인의 프레임, 이미지, 오디오, 동영상을 허용합니다. (frame-src, img-src, media-src)
• 번들 및 블롭(font-src)의 글꼴 허용
• 인라인 CSS 또는 번들의 CSS 허용(style-src)
• <object>, <embed>, <base> 요소는 사용할 수 없습니다(object-src, base-uri).
• 다른 CSP 적용 요청(default-src)에 대해서는 번들의 리소스만 허용합니다.

참고: IWA의 경우 self는 번들에서 로드된 리소스를 나타냅니다. blob:, filesystem:, 기타 로컬 스키마와 인라인 스크립트는 제외됩니다.

Content-Security-Policy: script-src 'self' 'wasm-unsafe-eval';
  connect-src 'self' https: wss: blob: data:;
  require-trusted-types-for 'script';
  frame-src 'self' https: blob: data:;
  img-src 'self' https: blob: data:;
  media-src 'self' https: blob: data:;
  font-src 'self' blob: data:;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  default-src 'self';

이러한 CSP는 잠재적으로 악의적인 서드 파티 코드를 완전히 보호하기에 충분하지 않습니다. IWA는 교차 출처 격리되어 서드 파티 리소스가 IWA에 영향을 미치는 기능을 줄이도록 헤더를 설정합니다.

• 번들의 리소스 또는 교차 출처 리소스만 허용합니다. 교차 출처 리소스는 교차 출처 리소스 정책 (CORP) 헤더가 설정되거나 crossorigin 속성이 있는 CORS를 지원하는 것으로 명시적으로 표시됩니다. (Cross-Origin-Embedder-Policy)
• CORS가 아닌 교차 출처 요청 허용 안 함(Cross-Origin-Resource-Policy)
• 교차 출처 문서에서 브라우징 컨텍스트를 프로세스 격리하여 window.opener 참조 및 전역 객체 액세스(Cross-Origin-Opener-Policy) 방지
• 사이트가 프레임 또는 iframe 내에 삽입되지 않도록 방지(CSP, frame-ancestors)

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Content-Security-Policy: frame-ancestors 'self'

이러한 제한이 적용되더라도 IWA가 방지하는 또 다른 잠재적 공격이 있습니다. 바로 시퀀스 중단 공격입니다. 시퀀스 중단 공격은 악성 서드 파티 콘텐츠가 내부 설정 페이지로 직접 이동하는 등 예상치 못한 방식으로 페이지로 이동하여 혼란스럽고 잠재적으로 악용 가능한 사용자 환경을 만들려고 할 때 발생합니다. IWA는 외부 사이트에서 임의의 딥 링크를 허용하지 않고 애플리케이션이 start_url, 프로토콜 핸들러, 공유 타겟 또는 실행 핸들러와 같이 잘 정의된 진입점으로 이동하여 열리도록만 허용하여 이를 방지합니다.

잠김

패키징과 격리는 실행이 허용되는 항목과 출처에 관한 일련의 보증을 제공하지만 웹의 권한은 동적이므로 이러한 보증만으로는 웹 애플리케이션이 필요한 기능만 사용하고 있는지 확인할 수 없습니다. 기능마다 보안 고려사항이 다르므로 사용자와 관리자는 앱을 설치하거나 업데이트하기 전에 Android 및 iOS와 같은 다른 네이티브 앱에서와 마찬가지로 IWA가 사용할 수 있는 권한을 감사하려고 합니다.

이를 용이하게 하기 위해 분리형 웹 앱은 기본적으로 모든 권한 요청을 차단합니다. 그런 다음 개발자는 웹 앱 매니페스트에 permissions_policy 필드를 추가하여 필요한 권한을 선택할 수 있습니다. 이 필드에는 IWA, 또는 하위 프레임(예: 관리 프레임 또는 iframe)이 요청할 수 있는 각 권한의 권한 정책 지시어 및 권한 정책 허용 목록의 키/값 쌍이 포함됩니다. 여기에 권한을 추가해도 자동으로 부여되지는 않습니다. 대신 해당 기능에 대한 요청이 이루어질 때 요청할 수 있게 됩니다.

예를 들어 차량 추적 IWA를 빌드한다고 가정해 보겠습니다. 사용자의 위치를 요청하고 삽입된 지도에서 위치를 요청하려면 IWA가 필요할 수 있습니다. 또한 사용자를 위해 몰입형 뷰를 제공할 수 있도록 삽입된 사이트가 전체 화면으로 전환될 수 있도록 하는 것이 좋습니다. 이렇게 하려면 웹 앱 매니페스트에서 다음 권한 정책을 설정합니다.

"permissions_policy": {
   "geolocation": [ "self", "https://map.example.com" ],
   "fullscreen": [ "*" ]
}

WebBundle은 Permissions Policy 헤더도 지정할 수 있으므로 둘 다에 선언된 권한만 허용되고 둘 다에 있는 허용 목록의 출처만 허용됩니다.

이름이 지정되고 버전이 지정됨

일반 웹 앱은 도메인 이름을 사용하여 사용자에게 자신을 식별하며 해당 도메인에서 제공되는 코드를 변경하여 업데이트할 수 있습니다. 하지만 격리된 웹 앱에 관한 보안 제약으로 인해 ID와 업데이트는 다르게 처리해야 합니다. 프로그레시브 웹 앱과 마찬가지로 분리형 웹 앱은 웹 앱 매니페스트 파일이 있어야 사용자에게 식별됩니다.

도움말: 설치 시 검색할 수 있어야 하므로 격리된 웹 앱의 웹 앱 매니페스트는 HTML에 연결되지 않습니다. /.well-known/manifest.webmanifest에 있어야 하며 IWA 패키지에 포함

해야 합니다.

웹 앱 매니페스트

분리형 웹 앱은 PWA와 동일한 키 매니페스트 속성을 웹 앱 매니페스트에 공유하지만 약간의 차이가 있습니다. 예를 들어 display는 약간 다르게 작동합니다. browser와 minimal-ui는 모두 minimal-ui 디스플레이로 강제되고 fullscreen와 standalone는 모두 standalone 디스플레이로 강제됩니다 (추가 display_override 옵션은 예상대로 작동함). 또한 version 및 update_manifest_url이라는 두 필드를 더 포함해야 합니다.

• version: 분리형 웹 앱에 필수입니다. 점 (.)으로 구분된 하나 이상의 정수로 구성된 문자열입니다. 버전은 1, 2, 3 등과 같이 간단할 수도 있고 SemVer (1.2.3)와 같이 복잡할 수도 있습니다. 버전 번호는 정규식 ^(\d+.?)*\d$와 일치해야 합니다.
• update_manifest_url: 선택사항이지만 웹 애플리케이션 업데이트 매니페스트를 가져올 수 있는 HTTPS URL (또는 테스트용 localhost)을 가리키는 필드를 사용하는 것이 좋습니다.

분리형 웹 앱의 최소 웹 앱 매니페스트는 다음과 같을 수 있습니다.

{
  "name": "IWA Kitchen Sink",
  "version": "0.1.0",
  "update_manifest_url": "https://example.com/updates.json",
  "start_url": "/",
  "icons": [
    {
      "src": "/images/icon.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "any"
    },
    {
      "src": "/images/icon-mask.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "maskable"
    }
  ]
}

웹 애플리케이션 업데이트 매니페스트

웹 애플리케이션 업데이트 매니페스트는 지정된 웹 애플리케이션의 각 버전을 설명하는 JSON 파일입니다. JSON 객체에는 필수 필드인 version가 하나 포함되어 있습니다. 이 필드는 version, src, channels가 포함된 객체 목록입니다.

• version - 애플리케이션의 버전 번호로, 웹 앱 매니페스트의 version 필드와 동일합니다.
• src - 해당 버전의 호스팅 번들 (.swbn 파일)을 가리키는 HTTPS URL (또는 테스트용 localhost)입니다. 상대 URL은 웹 애플리케이션 업데이트 매니페스트 파일을 기준으로 합니다.
• channels - 이 버전이 속한 업데이트 채널을 식별하는 문자열 목록입니다. 다른 채널이 선택되지 않은 경우 사용할 기본 채널을 설명하는 데 특수 default 채널이 사용됩니다.

channels 필드, 즉 각 ID에 선택적 name 속성이 있는 채널 ID 객체를 포함하여 default 채널을 포함한 사람이 읽을 수 있는 이름을 제공할 수도 있습니다. name 속성이 포함되지 않거나 channels 객체에 포함되지 않은 채널은 ID를 이름으로 사용합니다.

최소 업데이트 매니페스트는 다음과 같습니다.

{
  "versions": [
    {
      "version": "5.2.17",
      "src": "https://cdn.example.com/app-package-5.2.17.swbn",
      "channels": ["next", "5-lts", "default"]
    },
    {
      "version": "5.3.0",
      "src": "v5.3.0/package.swbn",
      "channels": ["next", "default"]
    },
    {
      "version": "5.3.1",
      "src": "v5.3.1/package.swbn",
      "channels": ["next"]
    },
  ],
  "channels": {
    "default": {
      "name": "Stable"
    },
    "5-lts": {
      "name": "5.x Long-term Stable"
    }
  }
}

이 예시에는 Stable 라벨이 지정될 default, 5.x Long-term Stable 라벨이 지정될 5-lts, next 라벨이 지정될 next의 세 가지 채널이 있습니다. 사용자가 채널 5-lts에 있으면 버전 5.2.17이 표시되고, 채널 default에 있으면 버전 5.3.0이 표시되며, 채널 next에 있으면 버전 5.3.1이 표시됩니다.

웹 애플리케이션 업데이트 매니페스트는 모든 서버에서 호스팅할 수 있습니다. 업데이트는 4~6시간마다 확인됩니다.

관리자 관리

초기 출시에서는 분리형 웹 앱이 관리 패널을 통해 관리자가 Chrome Enterprise 관리 Chromebook에만 설치할 수 있습니다.

시작하려면 관리 패널에서 기기 > Chrome > 앱 및 확장 프로그램 > 사용자 및 브라우저로 이동합니다. 이 탭에서는 조직 전체의 사용자를 위해 Chrome 웹 스토어, Google Play, 웹에서 앱과 확장 프로그램을 추가할 수 있습니다. 항목을 추가하려면 화면 오른쪽 하단에 있는 노란색 플로팅 추가 (+) 버튼을 열고 추가할 항목 유형을 선택합니다.

도움말: 조직 단위 (OU) 수준에서만 항목을 추가할 수 있습니다. 앱 및 확장 프로그램 페이지의 사이드바 패널에서 조직 단위를 선택하지 않았거나 사용자 및 브라우저 탭에 있지 않으면 추가 버튼이 표시되지 않습니다.

열면 분리형 웹 앱 추가라는 라벨이 지정된 정사각형 안에 정사각형 아이콘이 표시됩니다. 이 아이콘을 클릭하면 OU에 IWA를 추가하는 모달이 열립니다. 이렇게 하려면 IWA의 웹 번들 ID (앱의 공개 키에서 생성되며 앱이 번들링되고 서명된 후 표시됨)와 IWA의 웹 앱 업데이트 매니페스트 URL이라는 두 가지 정보가 필요합니다. 설치 후에는 관리 패널의 표준 옵션 세트를 사용하여 관리할 수 있습니다.

• 설치 정책: IWA를 설치하는 방법입니다. 강제 설치하거나, 강제 설치하고 ChromeOS 앱 표시줄에 고정하거나, 설치를 방지할 수 있습니다.
• 로그인 시 실행: IWA를 실행하는 방법입니다. 사용자가 수동으로 실행하도록 허용하거나, 사용자가 로그인할 때 IWA를 강제 실행하되 닫을 수 있도록 허용하거나, 사용자가 로그인할 때 강제 실행하고 닫지 못하도록 할 수 있습니다.

저장되면 해당 OU의 Chromebook에 정책 업데이트가 적용될 때 앱이 설치됩니다. 설치되면 사용자의 기기에서 4~6시간마다 웹 앱 업데이트 매니페스트의 업데이트를 확인합니다.

IWA를 강제 설치하는 것 외에도 다른 웹 애플리케이션과 마찬가지로 IWA에 대한 일부 권한을 자동으로 부여할 수 있습니다. 이렇게 하려면 기기 > Chrome > 웹 기능으로 이동하여 출처 추가 버튼을 클릭합니다. Origin / site pattern field에 IWA의 웹 번들 ID를 붙여넣습니다(isolated-app://이 프로토콜로 자동 추가됨). 여기에서 창 관리, 로컬 글꼴 관리, 화면 모니터링 API를 비롯한 다양한 API의 액세스 수준 (허용/차단/설정 안 함)을 설정할 수 있습니다. 관리자가 사용 설정하기 위해 추가 선택이 필요할 수 있는 API(예: 필수 화면 모니터링 API)의 경우 선택을 확인하는 추가 대화상자가 표시됩니다. 완료되면 변경사항을 저장하고 사용자가 IWA를 사용할 수 있습니다.

확장 프로그램 작업

분리형 웹 앱은 기본적으로 확장 프로그램과 호환되지 않지만 소유한 확장 프로그램을 연결할 수 있습니다. 이렇게 하려면 확장 프로그램의 매니페스트 파일을 수정해야 합니다. 매니페스트의 externally_connectable 섹션에서는 확장 프로그램이 상호작용할 수 있는 외부 웹페이지 또는 기타 Chrome 확장 프로그램을 정의합니다. externally_connectable 내의 matches 필드 아래에 IWA의 출처를 추가합니다 (isolated-app:// 스킴을 포함해야 함).

{
  "externally_connectable": {
    "matches": ["isolated-app://79990854-bc9f-4319-a6f3-47686e54ed29/*"]
  }
}

이렇게 하면 확장 프로그램이 격리된 웹 앱에서 실행될 수 있지만 콘텐츠를 삽입할 수는 없습니다. 확장 프로그램과 IWA 간에 메시지를 전달하는 것만 가능합니다.