Keamanan

Bagian ini menjelaskan cara mengamankan data dengan menggunakan enkripsi saat menggunakan WorkSpaces layanan Amazon. Ini menjelaskan enkripsi dalam perjalanan dan saat istirahat, dan penggunaan kelompok keamanan untuk melindungi akses jaringan ke jaringan WorkSpaces. Bagian ini juga memberikan informasi tentang cara mengontrol akses perangkat akhir WorkSpaces dengan menggunakan Perangkat Tepercaya, dan Grup Kontrol Akses IP.

Informasi tambahan tentang otentikasi (termasuk dukungan MFA) di Directory AWS Service dapat ditemukan di bagian ini.

Enkripsi dalam bergerak

Amazon WorkSpaces menggunakan kriptografi untuk melindungi kerahasiaan pada berbagai tahap komunikasi (dalam perjalanan) dan juga untuk melindungi data saat istirahat (terenkripsi). WorkSpaces Proses di setiap tahap enkripsi yang digunakan oleh Amazon WorkSpaces dalam perjalanan dijelaskan di bagian berikut.

Untuk informasi tentang enkripsi saat istirahat, lihat WorkSpaces bagian Terenkripsi dari dokumen ini.

Pendaftaran dan pembaruan

Aplikasi klien desktop berkomunikasi dengan Amazon untuk pembaruan dan pendaftaran menggunakan HTTPS.

Tahap otentikasi

Klien desktop memulai otentikasi dengan mengirimkan kredensyal ke gateway otentikasi. Komunikasi antara klien desktop dan gateway otentikasi menggunakan HTTPS. Pada akhir tahap ini, jika otentikasi berhasil, gateway otentikasi mengembalikan token OAuth 2.0 ke klien desktop, melalui koneksi HTTPS yang sama.

catatan

Aplikasi klien desktop mendukung penggunaan server proxy untuk lalu lintas port 443 (HTTPS), untuk pembaruan, pendaftaran, dan otentikasi.

Setelah menerima kredensi dari klien, gateway otentikasi mengirimkan permintaan otentikasi ke Directory Service. AWS Komunikasi dari gateway otentikasi ke AWS Directory Service berlangsung melalui HTTPS, sehingga tidak ada kredensi pengguna yang ditransmisikan dalam plaintext.

Otentikasi - Konektor Direktori Aktif (ADC)

AD Connector menggunakan Kerberos untuk membuat komunikasi terautentikasi dengan AD lokal, sehingga dapat mengikat ke LDAP dan menjalankan kueri LDAP berikutnya. Dukungan LDAPS sisi klien di ADC juga tersedia untuk mengenkripsi kueri antara Microsoft AD dan Aplikasi. AWS Sebelum menerapkan fungsionalitas LDAPS sisi klien, tinjau prasyarat untuk LDAPS sisi klien.

AWS Directory Service juga mendukung LDAP dengan TLS. Tidak ada kredensi pengguna yang dikirimkan dalam plaintext kapan saja. Untuk meningkatkan keamanan, dimungkinkan untuk menghubungkan WorkSpaces VPC dengan jaringan lokal (tempat AD berada) menggunakan koneksi VPN. Saat menggunakan koneksi VPN AWS perangkat keras, pelanggan dapat mengatur enkripsi dalam perjalanan dengan menggunakan IPSEC standar (Internet Key Exchange (IKE) dan IPSEC SA) dengan kunci enkripsi simetris AES-128 atau AES-256, SHA-1 atau SHA-256 untuk hash integritas, dan grup DH (2,14-18, 22, 23 dan 24 untuk fase 1; 1,2,5, 14-18, 22, 23 dan 24 untuk fase 2) menggunakan kerahasiaan maju sempurna (PFS).

Tahap broker

Setelah menerima token OAuth 2.0 (dari gateway otentikasi, jika otentikasi berhasil), klien desktop menanyakan WorkSpaces layanan Amazon (Broker Connection Manager) menggunakan HTTPS. Klien desktop mengotentikasi dirinya sendiri dengan mengirimkan token OAuth 2.0 dan, sebagai hasilnya, klien menerima informasi titik akhir dari gateway streaming. WorkSpaces

Panggung streaming

Klien desktop meminta untuk membuka sesi PCoIP dengan gateway streaming (menggunakan token OAuth 2.0). Sesi ini dienkripsi AES-256 dan menggunakan port PCoIP untuk kontrol komunikasi (4172/TCP).

Menggunakan token OAuth2.0, gateway streaming meminta informasi khusus pengguna WorkSpaces dari WorkSpaces layanan Amazon, melalui HTTPS.

Gateway streaming juga menerima TGT dari klien (yang dienkripsi menggunakan kata sandi pengguna klien) dan, dengan menggunakan pass-through Kerberos TGT, gateway memulai login Windows di, menggunakan Kerberos TGT yang diambil pengguna. WorkSpace

WorkSpace Kemudian memulai permintaan otentikasi ke AWS Directory Service yang dikonfigurasi, menggunakan otentikasi Kerberos standar.

Setelah berhasil masuk, streaming PCoIP dimulai. WorkSpace Koneksi dimulai oleh klien pada port TCP 4172 dengan lalu lintas kembali pada port UDP 4172. Selain itu, koneksi awal antara gateway streaming dan WorkSpaces desktop melalui antarmuka manajemen adalah melalui UDP 55002. (Lihat dokumentasi untuk Alamat IP dan Persyaratan Port untuk Amazon WorkSpaces. Port UDP keluar awal adalah 55002.) Koneksi streaming, menggunakan port 4172 (TCP dan UDP), dienkripsi dengan menggunakan cipher AES 128- dan 256-bit, tetapi default ke 128-bit. Pelanggan dapat secara aktif mengubah ini menjadi 256-bit, baik menggunakan pengaturan Kebijakan Grup AD khusus PCOIP untuk Windows, atau dengan file WorkSpaces pcoip-agent.conf untuk Amazon Linux. WorkSpaces Untuk informasi selengkapnya tentang Administrasi Kebijakan Grup untuk Amazon WorkSpaces, lihat dokumentasi.

Antarmuka jaringan

Setiap Amazon WorkSpace memiliki dua antarmuka jaringan, yang disebut antarmuka jaringan utama dan antarmuka jaringan manajemen.

Antarmuka jaringan utama menyediakan konektivitas ke sumber daya di dalam VPC pelanggan, seperti akses ke AWS Directory Service, internet, dan jaringan perusahaan pelanggan. Dimungkinkan untuk melampirkan grup keamanan ke antarmuka jaringan utama ini. Secara konseptual, kelompok keamanan dibedakan melekat pada ENI ini berdasarkan ruang lingkup penyebaran: kelompok keamanan dan kelompok WorkSpaces keamanan ENI.

Antarmuka jaringan manajemen

Antarmuka jaringan manajemen tidak dapat dikontrol melalui grup keamanan; Namun, pelanggan dapat menggunakan firewall berbasis host WorkSpaces untuk memblokir port atau mengontrol akses. Kami tidak menyarankan menerapkan batasan pada antarmuka jaringan manajemen. Jika pelanggan memutuskan untuk menambahkan aturan firewall berbasis host untuk mengelola antarmuka ini, beberapa port harus terbuka sehingga WorkSpaces layanan Amazon dapat mengelola kesehatan dan aksesibilitas ke. WorkSpace Untuk informasi selengkapnya, lihat Antarmuka Jaringan di Panduan Administrasi Ruang Kerja Amazon.

WorkSpaces kelompok keamanan

Grup keamanan default dibuat per AWS Directory Service dan secara otomatis dilampirkan ke semua WorkSpaces yang dimiliki oleh direktori tertentu.

Amazon WorkSpaces, seperti banyak AWS layanan lainnya, memanfaatkan kelompok keamanan. Amazon WorkSpaces membuat dua Grup AWS Keamanan saat Anda mendaftarkan direktori dengan WorkSpaces layanan. Satu untuk pengontrol direktori DirectoryID_Controllers dan satu untuk di direktori DirectoryID_WorkspacesMembers. WorkSpaces Jangan menghapus salah satu dari grup keamanan ini, atau Anda WorkSpaces akan menjadi terganggu. Secara default, grup keamanan WorkSpaces Anggota memiliki jalan keluar terbuka ke 0.0.0.0/0. Anda dapat menambahkan grup WorkSpaces keamanan default ke direktori. Setelah Anda mengaitkan grup keamanan baru dengan WorkSpaces direktori, baru WorkSpaces yang Anda luncurkan atau WorkSpaces yang sudah ada yang Anda bangun kembali akan memiliki grup keamanan baru. Anda juga dapat menambahkan grup keamanan default baru ini ke yang sudah ada WorkSpaces tanpa membangunnya kembali. Saat Anda mengaitkan beberapa grup keamanan dengan WorkSpaces direktori, WorkSpaces gabungkan aturan dari setiap grup keamanan ke dalam satu set aturan. Kami merekomendasikan agar memadatkan aturan grup keamanan Anda sedapat mungkin. Untuk informasi selengkapnya tentang grup keamanan, lihat Grup Keamanan untuk VPC Anda di Panduan Pengguna Amazon VPC.

Untuk informasi selengkapnya tentang menambahkan grup keamanan ke WorkSpaces direktori atau yang sudah ada WorkSpace, lihat panduan WorkSpaces Admin.

Beberapa pelanggan ingin membatasi pelabuhan dan tujuan WorkSpaces lalu lintas dapat keluar. Untuk membatasi lalu lintas keluar dari WorkSpaces, Anda harus memastikan bahwa Anda meninggalkan port tertentu yang diperlukan untuk komunikasi layanan; jika tidak, pengguna Anda tidak akan dapat masuk ke port mereka. WorkSpaces

WorkSpaces memanfaatkan Elastic Network Interface (ENI) di VPC pelanggan untuk komunikasi ke pengontrol WorkSpace domain selama login. Agar pengguna Anda WorkSpaces berhasil masuk, Anda harus mengizinkan port berikut untuk mengakses pengontrol domain Anda atau rentang CIDR yang menyertakan pengontrol domain Anda di grup keamanan _WorkspacesMembers.

• TCP/UDP 53 - DNS

• TCP/UDP 88 - Autentikasi Kerberos

• TCP/UDP 389 — LDAP

• TCP/UDP 445 - SMB

• TCP 3268-3269 - Katalog Global

• TCP/UDP 464 - Perubahan kata sandi Kerberos

• TCP 139 - Netlogon

• UDP 137-138 - Netlogon

• UDP 123 - NTP

• Port TCP/UDP 49152-65535 Ephemeral untuk RPC

Jika Anda WorkSpaces perlu mengakses aplikasi lain, Internet, atau lokasi lain, Anda harus mengizinkan port dan tujuan tersebut dalam notasi CIDR dalam grup keamanan _WorkspacesMembers. Jika Anda tidak menambahkan port dan tujuan tersebut, tidak WorkSpaces akan mencapai apa pun selain port yang tercantum di atas. Satu pertimbangan terakhir, secara default, grup keamanan baru tidak memiliki aturan masuk. Oleh karena itu, tidak ada lalu lintas masuk yang berasal dari host lain ke instans Anda yang diperbolehkan hingga Anda menambahkan aturan masuk ke grup keamanan tersebut. Langkah-langkah di atas hanya diperlukan jika Anda ingin membatasi jalan keluar dari WorkSpaces atau mengunci aturan ingress hanya ke sumber daya atau rentang CIDR yang seharusnya memiliki akses ke sana.

catatan

Grup keamanan yang baru terkait akan dilampirkan hanya untuk WorkSpaces dibuat atau dibangun kembali setelah modifikasi.

Kelompok keamanan ENI

Karena antarmuka jaringan utama adalah ENI biasa, itu dapat dikelola dengan menggunakan alat AWS manajemen yang berbeda. Untuk informasi lebih lanjut, lihat Antarmuka Jaringan Elastis. Arahkan ke alamat WorkSpace IP (di WorkSpaces halaman di WorkSpaces konsol Amazon), lalu gunakan alamat IP itu sebagai filter untuk menemukan ENI yang sesuai (di bagian Antarmuka Jaringan dari konsol Amazon EC2).

Setelah ENI ditemukan, itu dapat langsung dikelola oleh kelompok keamanan. Saat menetapkan grup keamanan secara manual ke antarmuka jaringan utama, pertimbangkan persyaratan port Amazon WorkSpaces. Untuk informasi selengkapnya, lihat Antarmuka Jaringan di Panduan Administrasi Ruang Kerja Amazon.

Gambar 21: WorkSpaces klien dengan MFA diaktifkan

Daftar Kontrol Akses (ACL) Jaringan

Karena kompleksitas tambahan dalam mengelola firewall lain, ACL Jaringan biasanya digunakan dalam penerapan yang sangat kompleks dan umumnya tidak digunakan sebagai praktik terbaik. Karena ACL Jaringan dilampirkan ke subnet di VPC, yang memfokuskan fungsinya pada Layer 3 (Jaringan) model OSI. WorkSpaces Karena Amazon dirancang pada Layanan Direktori, dua subnet harus ditentukan. ACL Jaringan dikelola secara terpisah dari Layanan Direktori, dan sangat mungkin bahwa ACL Jaringan dapat ditetapkan hanya ke salah satu subnet yang WorkSpaces ditetapkan.

Ketika firewall stateless diperlukan, ACL Jaringan adalah praktik terbaik untuk keamanan. Pastikan setiap perubahan yang dilakukan pada ACL Jaringan di luar pengaturan default divalidasi berdasarkan per subnet sebagai praktik terbaik. Jika ACL Jaringan tidak berfungsi sebagaimana dimaksud, pertimbangkan untuk menggunakan VPC Flow Logs untuk menganalisis lalu lintas.

AWS Network Firewall

AWS Network Firewall menawarkan fungsionalitas di luar apa yang ditawarkan Grup Keamanan asli dan ACL Jaringan, namun dengan biaya tertentu. Ketika pelanggan telah meminta kemampuan untuk meningkatkan keamanan di sekitar koneksi jaringan seperti Server Name Inspection (SNI) untuk situs web berbasis HTTP, Intrusion Detection and Prevent, dan daftar allow and deny untuk nama domain, mereka dibiarkan mencari firewall alternatif di. AWS Marketplace Kompleksitas dalam menerapkan firewall ini menghadirkan tantangan di luar keahlian administrator EUC standar. AWS Network Firewall menawarkan AWS pengalaman asli sambil mengaktifkan perlindungan Layers 3 hingga 7. Menggunakan AWS Network Firewall bersama dengan NAT Gateway adalah praktik terbaik ketika organisasi tidak memiliki sarana lain (lisensi lokal yang ada untuk firewall pihak ketiga yang dapat ditransfer ke cloud atau tim terpisah yang mengelola firewall yang dikecualikan) untuk mencakup semua perlindungan jaringan EUC. NAT Gateway juga gratis dengan AWS Network Firewall.

Penerapan AWS Network Firewall dirancang di sekitar desain EUC yang ada. Desain VPC tunggal dapat mencapai arsitektur yang disederhanakan dengan subnet untuk titik akhir firewall dan pertimbangan perutean jalan keluar Internet yang terpisah, sedangkan desain multi VPC mendapat manfaat besar dari VPC inspeksi terkonsolidasi dengan firewall dan titik akhir Transit Gateways.

Skenario desain

Skenario 1: Lockdown instance dasar

Grup WorkSpaces Keamanan default tidak mengizinkan lalu lintas masuk, karena Grup Keamanan ditolak secara default, dan stateful. Ini berarti bahwa tidak ada konfigurasi tambahan yang perlu dikonfigurasi untuk lebih mengamankan WorkSpaces instance itu sendiri. Pertimbangkan aturan keluar yang memungkinkan semua lalu lintas, dan jika itu sesuai dengan kasus penggunaan. Misalnya, mungkin yang terbaik adalah menolak semua lalu lintas keluar ke port 443 ke alamat apa pun, dan rentang IP spesifik yang sesuai dengan kasus penggunaan port seperti 389 untuk LDAP, 636 untuk LDAP, 445 untuk SMB, antara lain; meskipun perhatikan kompleksitas lingkungan mungkin memerlukan beberapa aturan dan dengan demikian lebih baik dilayani melalui ACL Jaringan atau alat firewall.

Skenario 2: Pengecualian masuk

Meskipun ini bukan persyaratan konstan, mungkin ada kalanya lalu lintas jaringan dimulai masuk ke. WorkSpaces Misalnya, triaging instance ketika WorkSpaces Klien tidak dapat terhubung memerlukan konektivitas jarak jauh alternatif. Dalam hal ini, yang terbaik adalah mengaktifkan sementara TCP 3389 masuk ke Grup Keamanan ENI pelanggan. WorkSpace

Skenario lain adalah skrip organisasi yang melakukan perintah untuk fungsi inventaris atau otomatisasi, yang diprakarsai oleh instance terpusat. Mengamankan lalu lintas pada port itu dari instance terpusat tertentu pada Inbound dapat dikonfigurasi secara permanen, namun, ini adalah praktik terbaik untuk melakukan ini pada Grup Keamanan tambahan yang dilampirkan ke konfigurasi Direktori karena dapat diterapkan ke beberapa penerapan di akun. AWS

Terakhir, ada beberapa lalu lintas jaringan yang tidak berbasis stateful-based dan akan memerlukan port fana untuk ditentukan dalam pengecualian masuk. Jika kueri dan skrip gagal, itu adalah praktik terbaik untuk mengizinkan port sementara, setidaknya untuk sementara, sambil menentukan akar penyebab kegagalan konektivitas.

Skenario 3: Inspeksi VPC tunggal

Penyebaran sederhana WorkSpaces (seperti VPC tunggal tanpa rencana penskalaan) tidak memerlukan VPC terpisah untuk inspeksi, dan dengan demikian koneksi ke VPC lain dapat disederhanakan dengan VPC VPC. Subnet terpisah, bagaimanapun, untuk titik akhir firewall harus dibuat dengan perutean yang dikonfigurasi ke titik akhir tersebut serta perutean jalan keluar Internet Gateway (IGW), yang jika tidak, tidak perlu dikonfigurasi. Penerapan yang ada mungkin tidak memiliki ruang IP yang tersedia jika semua subnet menggunakan seluruh blok CIDR VPC. Dalam kasus tersebut, Skenario 4 dapat berfungsi lebih baik karena penerapan telah diskalakan di luar desain awalnya.

Skenario 4: Inspeksi terpusat

Seringkali lebih disukai dalam beberapa penerapan EUC di suatu AWS Wilayah, menyederhanakan administrasi aturan stateful dan AWS stateless Network Firewall. Rekan VPC yang ada akan diganti dengan Transit Gateways, karena desain ini mengharuskan penggunaan lampiran Transit Gateway serta perutean inspeksi yang hanya dapat dikonfigurasi melalui lampiran tersebut. Tingkat kontrol yang lebih besar dilakukan atas konfigurasi ini juga, dan memungkinkan keamanan di luar WorkSpaces pengalaman default.

Gambar 22: Contoh arsitektur menggunakan lampiran Transit Gateway

Terenkripsi WorkSpaces

Setiap Amazon WorkSpace disediakan dengan volume root (C: drive untuk Windows WorkSpaces, root untuk Amazon Linux WorkSpaces) dan volume pengguna (D: drive untuk Windows WorkSpaces, /home untuk Amazon Linux). WorkSpaces WorkSpaces Fitur terenkripsi memungkinkan satu atau kedua volume dienkripsi.

Apa yang dienkripsi?

Data yang disimpan saat istirahat, disk input/output (I/O) ke volume, dan snapshot yang dibuat dari volume terenkripsi semuanya dienkripsi.

Kapan enkripsi terjadi?

Enkripsi untuk a WorkSpace harus ditentukan saat meluncurkan (membuat) file WorkSpace. WorkSpaces volume hanya dapat dienkripsi pada waktu peluncuran: setelah peluncuran, status enkripsi volume tidak dapat diubah. Gambar berikut menunjukkan halaman WorkSpaces konsol Amazon untuk memilih enkripsi selama peluncuran yang baru WorkSpace.

Gambar 23: Mengenkripsi volume root WorkSpace

Bagaimana cara baru WorkSpace dienkripsi?

Pelanggan dapat memilih WorkSpaces opsi Terenkripsi dari WorkSpaces konsol Amazon atau AWS CLI, atau dengan menggunakan WorkSpaces API Amazon saat pelanggan meluncurkan yang baru. WorkSpace

Untuk mengenkripsi volume, Amazon WorkSpaces menggunakan CMK from AWS Key Management Service ()AWS KMS. AWS KMS CMK default dibuat saat pertama kali WorkSpace diluncurkan di Wilayah. (CMK memiliki cakupan Wilayah.)

Pelanggan juga dapat membuat CMK yang dikelola pelanggan untuk digunakan dengan terenkripsi. WorkSpaces CMK digunakan untuk mengenkripsi kunci data yang digunakan oleh WorkSpaces layanan Amazon untuk mengenkripsi setiap volume. WorkSpace (Dalam arti yang ketat, Amazon EBS yang akan mengenkripsi volume). Untuk batas CMK saat ini, lihat Kuota AWS KMS sumber daya.

catatan

Membuat gambar kustom dari terenkripsi tidak WorkSpace didukung. Selain itu, WorkSpaces diluncurkan dengan enkripsi volume root yang diaktifkan dapat memakan waktu hingga satu jam untuk disediakan.

Untuk penjelasan rinci tentang proses WorkSpaces enkripsi, lihat Cara Amazon WorkSpaces menggunakan AWS KMS. Pertimbangkan bagaimana penggunaan CMK akan dipantau untuk memastikan bahwa permintaan untuk terenkripsi WorkSpace dilayani dengan benar. Untuk informasi tambahan tentang AWS KMS kunci dan kunci data, lihat AWS KMS halaman.

Opsi kontrol akses dan perangkat tepercaya

Amazon WorkSpaces menyediakan opsi kepada pelanggan untuk mengelola perangkat klien mana yang dapat diakses WorkSpaces. Pelanggan hanya dapat membatasi WorkSpaces akses ke perangkat tepercaya. Akses ke WorkSpaces dapat diizinkan dari macOS dan PC Microsoft Windows menggunakan sertifikat digital. Ini juga dapat memungkinkan atau memblokir akses untuk iOS, Android, Chrome OS, Linux, dan nol klien, serta klien Akses WorkSpaces Web. Dengan kemampuan ini, dapat lebih meningkatkan postur keamanan.

Opsi kontrol akses diaktifkan untuk penerapan baru bagi pengguna untuk mengakses WorkSpaces dari klien mereka di Windows, macOS, iOS, Android, ChromeOS, dan Zero Clients. Akses menggunakan Akses Web atau WorkSpaces klien Linux tidak diaktifkan secara default untuk WorkSpaces penerapan baru dan perlu diaktifkan.

Jika ada batasan akses data perusahaan dari perangkat tepercaya (juga dikenal sebagai perangkat terkelola), WorkSpaces akses dapat dibatasi ke perangkat tepercaya dengan sertifikat yang valid. Saat fitur ini diaktifkan, Amazon WorkSpaces menggunakan autentikasi berbasis sertifikat untuk menentukan apakah perangkat dipercaya. Jika aplikasi WorkSpaces klien tidak dapat memverifikasi bahwa perangkat dipercaya, ia memblokir upaya untuk masuk atau menyambung kembali dari perangkat.

Dukungan perangkat tepercaya tersedia untuk klien berikut:

• Aplikasi Amazon WorkSpaces Android Client di Google Play yang berjalan di perangkat Chrome OS yang kompatibel dengan Android dan Android

• Aplikasi Klien Amazon WorkSpaces macOS berjalan di perangkat macOS

• Aplikasi Amazon WorkSpaces Windows Client berjalan di perangkat Windows

Untuk informasi selengkapnya tentang mengontrol perangkat mana yang dapat diakses WorkSpaces, lihat Batasi WorkSpaces Akses ke Perangkat Tepercaya.

catatan

Sertifikat untuk perangkat tepercaya hanya berlaku untuk klien Amazon WorkSpaces Windows, macOS, dan Android. Fitur ini tidak berlaku untuk klien Amazon WorkSpaces Web Access, atau klien pihak ketiga mana pun, termasuk namun tidak terbatas pada perangkat lunak Teradici PCoIP dan klien seluler, klien Teradici PCoIP nol, klien RDP, dan aplikasi desktop jarak jauh.

Grup kontrol Akses IP

Dengan menggunakan grup kontrol berbasis alamat IP, pelanggan dapat menentukan dan mengelola grup alamat IP tepercaya, dan memungkinkan pengguna untuk mengakses WorkSpaces hanya ketika mereka terhubung ke jaringan tepercaya. Fitur ini membantu pelanggan mendapatkan kontrol yang lebih besar atas postur keamanan mereka.

Grup kontrol akses IP dapat ditambahkan di tingkat WorkSpaces direktori. Ada dua cara untuk memulai menggunakan grup kontrol akses IP.

• Halaman Kontrol Akses IP — Dari konsol WorkSpaces manajemen, grup kontrol akses IP dapat dibuat di halaman Kontrol Akses IP. Aturan dapat ditambahkan ke grup ini dengan memasukkan alamat IP atau rentang IP dari mana WorkSpaces dapat diakses. Kelompok-kelompok ini kemudian dapat ditambahkan ke direktori di halaman Perbarui Detail.

• API Workspace — WorkSpaces API dapat digunakan untuk membuat, menghapus, dan melihat grup; membuat atau menghapus aturan akses; atau untuk menambah dan menghapus grup dari direktori.

Untuk penjelasan rinci tentang menggunakan grup kontrol akses IP dengan proses WorkSpaces enkripsi Amazon, lihat Grup Kontrol Akses IP untuk Anda WorkSpaces.

Pemantauan atau pencatatan menggunakan Amazon CloudWatch

Pemantauan jaringan, server, dan log merupakan bagian integral dari infrastruktur apa pun. Pelanggan yang menggunakan Amazon WorkSpaces perlu memantau penyebaran mereka, khususnya kesehatan dan status koneksi individu secara keseluruhan. WorkSpaces

CloudWatch Metrik Amazon untuk WorkSpaces

CloudWatch metrik untuk WorkSpaces dirancang untuk memberikan administrator wawasan tambahan tentang kesehatan secara keseluruhan dan status koneksi individu. WorkSpaces Metrik tersedia per WorkSpace, atau digabungkan untuk semua WorkSpaces dalam organisasi dalam direktori tertentu.

Metrik ini, seperti semua CloudWatch metrik, dapat dilihat di AWS Management Console (ditunjukkan pada gambar berikut), diakses melalui CloudWatch API, dan dipantau oleh CloudWatch alarm dan alat pihak ketiga.

Gambar 24: CloudWatch metrik:/ ConnectionAttempt ConnectionFailure

Secara default, metrik berikut diaktifkan dan tersedia tanpa biaya tambahan:

• Tersedia — WorkSpaces yang menanggapi pemeriksaan status dihitung dalam metrik ini.

• Tidak sehat — WorkSpaces yang tidak menanggapi pemeriksaan status yang sama dihitung dalam metrik ini.

• ConnectionAttempt— Jumlah upaya koneksi yang dilakukan ke a WorkSpace.

• ConnectionSuccess— Jumlah upaya koneksi yang berhasil.

• ConnectionFailure— Jumlah upaya koneksi yang gagal.

• SessionLaunchTime— Jumlah waktu yang dibutuhkan untuk memulai sesi, yang diukur oleh WorkSpaces klien.

• InSessionLatency— Waktu pulang-pergi antara WorkSpaces klien dan WorkSpaces, sebagaimana diukur dan dilaporkan oleh klien.

• SessionDisconnect— Jumlah sesi yang dimulai pengguna dan ditutup secara otomatis.

Selain itu, alarm dapat dibuat, seperti yang ditunjukkan pada gambar berikut.

Gambar 25: Buat CloudWatch alarm untuk kesalahan WorkSpaces koneksi

CloudWatch Acara Amazon untuk WorkSpaces

Acara dari Amazon CloudWatch Events dapat digunakan untuk melihat, mencari, mengunduh, mengarsipkan, menganalisis, dan menanggapi login yang berhasil. WorkSpaces Layanan ini dapat memantau alamat IP WAN klien, Sistem Operasi, WorkSpaces ID, dan informasi ID Direktori untuk login pengguna. WorkSpaces Misalnya, dapat menggunakan acara untuk tujuan berikut:

• Simpan atau arsipkan peristiwa WorkSpaces login sebagai log untuk referensi future, analisis log untuk mencari pola, dan mengambil tindakan berdasarkan pola tersebut.

• Gunakan alamat IP WAN untuk menentukan dari mana pengguna masuk, dan kemudian gunakan kebijakan untuk mengizinkan pengguna mengakses hanya ke file atau data WorkSpaces yang memenuhi kriteria akses yang ditemukan dalam tipe CloudWatch Event WorkSpaces Access.

• Menggunakan kontrol kebijakan untuk memblokir akses ke file dan aplikasi dari alamat IP yang tidak sah.

Untuk informasi selengkapnya tentang cara menggunakan CloudWatch Acara, lihat Panduan Pengguna CloudWatch Acara Amazon. Untuk mempelajari lebih lanjut tentang CloudWatch Acara WorkSpaces, lihat Memantau Acara Cloudwatch Anda WorkSpaces .

YubiKey dukungan untuk Amazon WorkSpaces

Untuk menambahkan lapisan keamanan tambahan, pelanggan sering memilih untuk mengamankan alat dan situs dengan otentikasi multifaktor. Beberapa pelanggan memilih untuk melakukan ini dengan Yubico YubiKey. Amazon WorkSpaces mendukung kode sandi satu kali (OTP) dan protokol otentikasi FIDO U2F dengan. YubiKeys

Amazon WorkSpaces saat ini mendukung mode OTP, dan tidak ada langkah tambahan yang diperlukan dari administrator atau pengguna akhir untuk menggunakan OTP YubiKey dengan. Pengguna dapat melampirkan mereka YubiKey ke komputer mereka, memastikan keyboard terfokus di dalam WorkSpace (khususnya di bidang di mana OTP perlu dimasukkan), dan menyentuh kontak emas padaYubiKey. Secara otomatis YubiKey akan memasukkan OTP ke bidang yang dipilih.

Untuk memanfaatkan mode FIDO U2F dengan YubiKey dan WorkSpaces, diperlukan langkah-langkah tambahan. Pastikan pengguna Anda mengeluarkan salah satu YubiKey model yang didukung ini untuk memanfaatkan pengalihan U2F dengan: WorkSpaces

• YubiKey 4

• YubiKey 5 NFC

• YubiKey 5 Nano

• YubiKey 5C

• YubiKey 5C Nano

• YubiKey 5 NFC

Untuk mengaktifkan pengalihan USB untuk YubiKey U2F

Secara default, pengalihan USB dinonaktifkan untuk PCoIP WorkSpaces; untuk memanfaatkan mode U2F dengan YubiKeys, Anda harus mengaktifkannya.

1. Pastikan Anda telah menginstal template administratif Kebijakan WorkSpaces Grup terbaru untuk PCoIP (32-Bit) atau templat administratif Kebijakan WorkSpaces Grup untuk PCoIP (64-Bit).

2. Pada administrasi direktori WorkSpace atau instans Amazon EC2 yang digabungkan ke WorkSpaces direktori Anda, buka alat Manajemen Kebijakan Grup (gpmc.msc) dan arahkan ke Variabel Sesi PCoIP.

3. Untuk memungkinkan pengguna mengganti setelan Anda, pilih Default Administrator yang Dapat Diganti. Jika tidak, pilih Not Overridable Administrator Defaults.

4. Buka Aktifkan/nonaktifkan USB dalam pengaturan sesi PCOIP.

5. Pilih Diaktifkan, lalu pilih OK.

6. Buka pengaturan Konfigurasi PCoIP USB yang diizinkan dan aturan perangkat yang tidak diizinkan.

7. Pilih Diaktifkan, dan di bawah Masukkan tabel otorisasi USB (maksimum sepuluh aturan), konfigurasikan aturan daftar izin perangkat USB Anda.

   1. Aturan otorisasi - 110500407. Nilai ini merupakan kombinasi dari Vendor ID (VID) dan Product ID (PID). Format untuk kombinasi VID/PID adalah1xxxxyyyy, di mana xxxx VID dalam format heksadesimal dan yyyy PID dalam format heksadesimal. Untuk contoh ini, 1050 adalah VID, dan 0407 adalah PID. Untuk nilai YubiKey USB lainnya, lihat Nilai ID YubiKey USB.

8. Di bawah Masukkan tabel otorisasi USB (maksimum sepuluh aturan), konfigurasikan aturan daftar blokir perangkat USB Anda.

   1. Untuk Aturan Tidak Otorisasi, atur string kosong. Ini berarti bahwa hanya perangkat USB dalam daftar otorisasi yang diizinkan.

      catatan

      Anda dapat menentukan maksimum 10 aturan otorisasi USB dan maksimum 10 aturan tidak otorisasi USB. Gunakan karakter vertical bar (|) untuk memisahkan beberapa aturan. Untuk informasi rinci tentang aturan otorisasi/tidak otorisasi, lihat Teradici PCoIP Standard Agent untuk Windows

9. Pilih OK.

10. Perubahan pengaturan Kebijakan Grup berlaku setelah pembaruan Kebijakan Grup berikutnya untuk WorkSpace dan setelah WorkSpace sesi dimulai ulang. Untuk menerapkan perubahan Kebijakan Grup, lakukan salah satu hal berikut:

    1. Reboot WorkSpace (di WorkSpaces konsol Amazon, pilih WorkSpace, lalu pilih Tindakan, Reboot WorkSpaces).

    2. Dalam prompt perintah administratif, masukkan gpupdate/force.

11. Setelah pengaturan berlaku, semua perangkat USB yang didukung akan dapat diarahkan ke WorkSpaces kecuali pembatasan dikonfigurasi melalui pengaturan aturan perangkat USB.

Setelah Anda mengaktifkan pengalihan USB untuk YubiKey U2F, Anda dapat memanfaatkan mode Fido U2F Anda YubiKey .