Lindungi aplikasi dengan Microsoft Defender untuk Kontrol Aplikasi Akses Bersyarat Aplikasi Cloud

Catatan

  • Kami telah mengganti nama Microsoft Cloud App Security. Sekarang disebut Microsoft Defender for Cloud Apps. Dalam beberapa minggu mendatang, kami akan memperbarui cuplikan layar dan instruksi di sini dan di halaman terkait. Untuk informasi selengkapnya tentang perubahan tersebut, lihat pengumuman ini. Untuk mempelajari selengkapnya tentang penggantian nama layanan keamanan Microsoft baru-baru ini, lihat blog Microsoft Ignite Security.

  • Microsoft Defender for Cloud Apps sekarang menjadi bagian dari Pertahanan Microsoft 365. Portal Pertahanan Microsoft 365 memungkinkan admin keamanan untuk melakukan tugas keamanan mereka di satu lokasi. Ini akan menyederhanakan alur kerja, dan menambahkan fungsionalitas layanan Pertahanan Microsoft 365 lainnya. Pertahanan Microsoft 365 akan menjadi rumah bagi pemantauan dan pengelolaan keamanan di seluruh identitas, data, perangkat, aplikasi, dan infrastruktur Microsoft Anda. Untuk informasi selengkapnya tentang perubahan ini, lihat Microsoft Defender for Cloud Apps di Pertahanan Microsoft 365.

Di tempat kerja saat ini, seringkali tidak cukup untuk mengetahui apa yang terjadi di lingkungan cloud Anda setelah fakta. Anda ingin menghentikan pelanggaran dan kebocoran secara real time, sebelum karyawan dengan sengaja atau tidak sengaja membahayakan data dan organisasi Anda. Penting untuk memungkinkan pengguna di organisasi Anda memanfaatkan layanan dan alat yang tersedia untuk mereka di aplikasi cloud dan membiarkan mereka membawa perangkat mereka sendiri berfungsi. Pada saat yang sama, Anda memerlukan alat untuk membantu melindungi organisasi Anda dari kebocoran data, dan pencurian data, secara real time. Microsoft Defender for Cloud Apps terintegrasi dengan Penyedia Identitas (IdP) apa pun untuk memberikan kemampuan ini dengan kontrol akses dan sesi. Jika Anda menggunakan Azure Active Directory (Azure AD) sebagai IdP Anda, kontrol ini terintegrasi dan disederhanakan untuk penyebaran yang lebih sederhana dan lebih disesuaikan yang dibangun di alat Akses Bersyarah Azure AD.

Catatan

  • Selain lisensi Defender untuk Cloud Apps yang valid, untuk menggunakan Defender untuk Cloud Apps Conditional Access App Control, Anda juga memerlukan lisensi Azure Active Directory P1, atau lisensi yang diperlukan oleh solusi IdP Anda.

Cara kerjanya

Kontrol Aplikasi Akses Bersyarat menggunakan arsitektur proksi terbalik dan terintegrasi dengan IdP Anda. Saat mengintegrasikan dengan akses bersyarat Azure AD, Anda dapat mengonfigurasi aplikasi untuk bekerja dengan Kontrol Aplikasi Akses Bersyarat hanya dengan beberapa klik, memungkinkan Anda untuk dengan mudah dan selektif menerapkan kontrol akses dan sesi pada aplikasi organisasi Anda berdasarkan kondisi apa pun di Akses Bersyarat. Kondisi menentukan siapa (pengguna atau grup pengguna) dan apa (aplikasi cloud mana) dan di mana (lokasi dan jaringan mana) kebijakan Akses Bersyarah diterapkan. Setelah menentukan kondisi, Anda dapat merutekan pengguna ke Defender untuk Cloud Apps tempat Anda dapat melindungi data dengan Kontrol Aplikasi Akses Bersyarah dengan menerapkan kontrol akses dan sesi.

Kontrol Aplikasi Akses Bersyarat memungkinkan akses dan sesi aplikasi pengguna dipantau dan dikontrol secara real time berdasarkan kebijakan akses dan sesi. Kebijakan akses dan sesi digunakan dalam portal Pertahanan Microsoft untuk Aplikasi Cloud untuk lebih menyempurnakan filter dan mengatur tindakan yang akan diambil pada pengguna. Dengan kebijakan akses dan sesi, Anda dapat:

  • Mencegah penyelundupan data: Anda dapat memblokir unduhan, potong, salin, dan cetak dokumen sensitif pada, misalnya, perangkat yang tidak dikelola.

  • Memerlukan konteks autentikasi: Anda dapat mengevaluasi kembali kebijakan Akses Bersyarat Azure AD saat tindakan sensitif terjadi dalam sesi. Misalnya, memerlukan autentikasi multifaktor saat mengunduh file yang sangat rahasia.

  • Lindungi saat diunduh: Alih-alih memblokir pengunduhan dokumen sensitif, Anda dapat mewajibkan dokumen diberi label dan dienkripsi saat berintegrasi dengan Perlindungan Informasi Microsoft Purview. Tindakan ini memastikan dokumen diproteksi dan akses pengguna dibatasi dalam sesi yang berpotensi berisiko.

  • Mencegah pengunggahan file yang tidak berlabel: Sebelum file sensitif diunggah, didistribusikan, dan digunakan oleh orang lain, penting untuk memastikan bahwa file sensitif memiliki label yang ditentukan oleh kebijakan organisasi Anda. Anda dapat memastikan bahwa file yang tidak berlabel dengan konten sensitif diblokir agar tidak diunggah hingga pengguna mengklasifikasikan konten.

  • Blokir potensi malware: Anda dapat melindungi lingkungan Anda dari malware dengan memblokir unggahan file yang berpotensi berbahaya. File apa pun yang diunggah atau diunduh dapat dipindai terhadap inteligensi ancaman Microsoft dan diblokir secara instan.

  • Memantau sesi pengguna untuk kepatuhan: Pengguna berisiko dipantau saat mereka masuk ke aplikasi dan tindakan mereka dicatat dari dalam sesi. Anda dapat menyelidiki dan menganalisis perilaku pengguna untuk memahami di mana, dan dalam kondisi apa, kebijakan sesi harus diterapkan di masa depan.

  • Blokir akses: Anda dapat memblokir akses secara terperinci untuk aplikasi dan pengguna tertentu tergantung pada beberapa faktor risiko. Misalnya, Anda dapat memblokirnya jika menggunakan sertifikat klien sebagai bentuk manajemen perangkat.

  • Memblokir aktivitas kustom: Beberapa aplikasi memiliki skenario unik yang berisiko, misalnya, mengirim pesan dengan konten sensitif di aplikasi seperti Microsoft Teams atau Slack. Dalam skenario semacam ini, Anda dapat memindai pesan untuk konten sensitif dan memblokirnya secara real time.

Cara kerja kontrol sesi

Membuat kebijakan sesi dengan Kontrol Aplikasi Akses Bersyarat memungkinkan Anda mengontrol sesi pengguna dengan mengalihkan pengguna melalui proksi terbalik alih-alih langsung ke aplikasi. Sejak saat itu, permintaan dan respons pengguna melalui aplikasi Defender untuk Cloud daripada langsung ke aplikasi.

Saat sesi dilindungi oleh proksi, semua URL dan cookie yang relevan digantikan oleh Defender untuk Cloud Apps. Misalnya, jika aplikasi mengembalikan halaman dengan tautan yang domainnya diakhiri dengan myapp.com, domain tautan diakhiri dengan sesuatu seperti *.mcas.ms, sebagai berikut:

URL Aplikasi URL yang diganti
myapp.com myapp.com.mcas.ms

Metode ini tidak mengharuskan Anda menginstal apa pun di perangkat sehingga ideal saat memantau atau mengontrol sesi dari perangkat yang tidak dikelola atau pengguna mitra.

Catatan

  • Teknologi kami menggunakan heuristik paten terbaik di kelasnya untuk mengidentifikasi dan mengontrol aktivitas yang dilakukan oleh pengguna di aplikasi target. Heuristik kami dirancang untuk mengoptimalkan dan menyeimbangkan keamanan dengan kegunaan. Dalam beberapa skenario langka, ketika memblokir aktivitas di sisi server membuat aplikasi tidak dapat digunakan, kami mengamankan aktivitas ini hanya di sisi klien, yang membuat mereka berpotensi rentan terhadap eksploitasi oleh orang dalam yang berbahaya.
  • Defender untuk Cloud Apps memanfaatkan Azure Data Center di seluruh dunia untuk memberikan performa yang dioptimalkan melalui geolokasi. Ini berarti bahwa sesi pengguna dapat dihosting di luar wilayah tertentu, tergantung pada pola lalu lintas dan lokasinya. Namun, untuk melindungi privasi Anda, tidak ada data sesi yang disimpan di pusat data ini.
  • Server proksi kami tidak menyimpan data tidak aktif. Saat penembolokan konten, kami mengikuti persyaratan yang ditata dalam RFC 7234 (penembolokan HTTP) dan hanya cache konten publik.

Identifikasi perangkat terkelola

Kontrol Aplikasi Akses Bersyarat memungkinkan Anda membuat kebijakan yang memperhitungkan apakah perangkat dikelola atau tidak. Untuk mengidentifikasi status perangkat, Anda dapat mengonfigurasi kebijakan akses dan sesi untuk memeriksa:

  • perangkat yang sesuai Microsoft Intune [hanya tersedia dengan Azure AD]
  • Perangkat yang bergabung dengan Hybrid Azure AD [hanya tersedia dengan Azure AD]
  • Kehadiran sertifikat klien dalam rantai tepercaya

perangkat Intune patuh dan Gabungan Azure AD Hibrid

Azure AD Conditional Access memungkinkan informasi perangkat yang patuh Intune dan Bergabung dengan Azure AD Hibrid untuk diteruskan langsung ke Aplikasi Defender untuk Cloud. Dari sana, kebijakan akses atau kebijakan sesi dapat dikembangkan yang menggunakan status perangkat sebagai filter. Untuk informasi selengkapnya, lihat Pengenalan manajemen perangkat di Azure Active Directory.

Catatan

Beberapa browser mungkin memerlukan konfigurasi tambahan seperti menginstal ekstensi. Untuk informasi selengkapnya, lihat Dukungan browser Akses Bersyarah.

Perangkat terautentikasi sertifikat klien

Mekanisme identifikasi perangkat dapat meminta autentikasi dari perangkat yang relevan menggunakan sertifikat klien. Anda dapat menggunakan sertifikat klien yang sudah ada yang sudah disebarkan di organisasi Anda atau meluncurkan sertifikat klien baru ke perangkat terkelola. Pastikan bahwa sertifikat klien diinstal di penyimpanan pengguna dan bukan penyimpanan komputer. Anda kemudian menggunakan keberadaan sertifikat tersebut untuk mengatur kebijakan akses dan sesi.

Sertifikat klien SSL diverifikasi melalui rantai kepercayaan. Anda dapat mengunggah otoritas sertifikat (CA) root atau intermediate certificate authority (CA) X.509 yang diformat dalam format sertifikat PEM. Sertifikat ini harus berisi kunci umum CA, yang kemudian digunakan untuk menandatangani sertifikat klien yang disajikan selama sesi.

Setelah sertifikat diunggah dan kebijakan yang relevan dikonfigurasi, ketika sesi yang berlaku melintasi Kontrol Aplikasi Akses Bersyarat, titik akhir Defender untuk Cloud Apps meminta browser untuk menyajikan sertifikat klien SSL. Browser melayani sertifikat klien SSL yang diinstal dengan kunci privat. Kombinasi sertifikat dan kunci privat ini dilakukan dengan menggunakan format file PKCS #12, biasanya .p12 atau .pfx.

Saat pemeriksaan sertifikat klien dilakukan, Defender untuk Cloud Apps memeriksa kondisi berikut:

  1. Sertifikat klien yang dipilih valid dan berada di bawah CA akar atau perantara yang benar.
  2. Sertifikat tidak dicabut (jika CRL diaktifkan).

Catatan

Sebagian besar browser utama mendukung melakukan pemeriksaan sertifikat klien. Namun, aplikasi seluler dan desktop sering memanfaatkan browser bawaan yang mungkin tidak mendukung pemeriksaan ini dan karenanya memengaruhi autentikasi untuk aplikasi ini.

Untuk mengonfigurasi kebijakan untuk memanfaatkan manajemen perangkat melalui sertifikat klien:

  1. Di Defender untuk Cloud Apps, di bilah menu, pilih pengaturan cog settings icon. dan pilih Pengaturan.

  2. Pilih tab Identifikasi perangkat .

  3. Upload sertifikat akar atau perantara sebanyak yang Anda butuhkan.

    Tip

    Untuk menguji cara kerjanya, Anda dapat menggunakan CA akar sampel dan sertifikat klien kami, sebagai berikut:

    1. Unduh sampel CA akar dan sertifikat klien.
    2. Upload OS akar ke aplikasi Defender untuk Cloud.
    3. Instal sertifikat klien (password=Microsoft) ke perangkat yang relevan.

Setelah sertifikat diunggah, Anda dapat membuat kebijakan akses dan sesi berdasarkan Tag perangkat dan Sertifikat klien yang valid.

Aplikasi dan klien yang didukung

Kontrol sesi dan akses dapat diterapkan ke akses menyeluruh interaktif apa pun, menggunakan protokol autentikasi SAML 2.0 atau, jika Anda menggunakan Azure AD, protokol autentikasi Open ID Koneksi juga. Selain itu, jika aplikasi Anda dikonfigurasi dengan Azure AD, Anda juga dapat menerapkan kontrol ini ke aplikasi yang dihosting secara lokal yang dikonfigurasi dengan Proksi Aplikasi Azure AD. Selain itu, kontrol akses dapat diterapkan ke aplikasi klien seluler dan desktop asli.

Defender untuk Cloud Apps mengidentifikasi Aplikasi menggunakan informasi yang tersedia di Katalog Aplikasi Cloud-nya. Beberapa organisasi dan pengguna menyesuaikan aplikasi dengan menambahkan plugin. Namun, agar kontrol sesi berfungsi dengan benar dengan plugin ini, domain kustom terkait harus ditambahkan ke aplikasi masing-masing dalam katalog.

Catatan

Aplikasi Authenticator, di antara alur masuk aplikasi klien asli lainnya, menggunakan alur masuk noninteraktif dan tidak dapat digunakan dengan kontrol akses.

Kontrol Akses

Banyak organisasi yang memilih untuk menggunakan kontrol sesi untuk aplikasi cloud guna mengontrol aktivitas dalam sesi, juga menerapkan kontrol akses untuk memblokir serangkaian aplikasi klien seluler dan desktop asli yang sama, sehingga memberikan keamanan komprehensif untuk aplikasi.

Anda dapat memblokir akses ke aplikasi klien seluler dan desktop asli dengan kebijakan akses, dengan mengatur filter aplikasi Klien ke Seluler dan desktop. Beberapa aplikasi klien asli dapat dikenali secara individual, sementara yang lain yang merupakan bagian dari rangkaian aplikasi hanya dapat diidentifikasi sebagai aplikasi tingkat atas mereka. Misalnya, aplikasi seperti SharePoint Online hanya dapat dikenali dengan membuat kebijakan akses yang diterapkan ke aplikasi Office 365.

Catatan

Kecuali filter aplikasi Klien secara khusus diatur ke Seluler dan desktop, kebijakan akses yang dihasilkan hanya akan berlaku untuk sesi browser. Alasan untuk ini adalah untuk mencegah secara tidak sengaja memproksi sesi pengguna, yang mungkin merupakan produk sampingan dari penggunaan filter ini. Sementara sebagian besar browser utama mendukung pemeriksaan sertifikat klien, beberapa aplikasi seluler dan desktop menggunakan browser bawaan yang mungkin tidak mendukung pemeriksaan ini. Oleh karena itu, menggunakan filter ini dapat memengaruhi autentikasi untuk aplikasi ini.

Kontrol sesi

Meskipun kontrol sesi dibuat untuk bekerja dengan browser apa pun di platform utama apa pun pada sistem operasi apa pun, kami mendukung Microsoft Edge (terbaru), Google Chrome (terbaru), Mozilla Firefox (terbaru), atau Apple Safari (terbaru). Akses ke aplikasi seluler dan desktop juga dapat diblokir atau diizinkan.

Catatan

  • Defender untuk Cloud Apps menggunakan protokol Transport Layer Security (TLS) 1.2+ untuk menyediakan enkripsi terbaik di kelasnya. Aplikasi klien asli dan browser yang tidak mendukung TLS 1.2+, tidak akan dapat diakses saat dikonfigurasi dengan kontrol sesi. Namun, aplikasi SaaS yang menggunakan TLS 1.1 atau lebih rendah akan muncul di browser seperti menggunakan TLS 1.2+ saat dikonfigurasi dengan Defender untuk Cloud Apps.
  • Untuk menerapkan kontrol sesi ke portal.office.com, Anda harus melakukan onboarding pusat admin Microsoft 365. Untuk informasi selengkapnya tentang aplikasi onboarding, lihat Onboarding dan sebarkan Kontrol Aplikasi Akses Bersyarah untuk aplikasi apa pun.

Aplikasi pra-onboarding

Aplikasi web apa pun yang dikonfigurasi menggunakan protokol autentikasi yang disebutkan sebelumnya dapat di-onboarding untuk bekerja dengan kontrol akses dan sesi. Selain itu, aplikasi berikut sudah di-onboarding dengan kontrol akses dan sesi untuk Azure Access Directory.

Catatan

Anda harus merutekan aplikasi yang Anda inginkan untuk mengakses dan mengontrol sesi, dan untuk melakukan login pertama.

  • AWS
  • Kotak
  • Concur
  • CornerStone sesuai Permintaan
  • Docusign
  • Dropbox
  • Egnyte
  • GitHub
  • Google Workspace
  • HighQ
  • JIRA/Confluence
  • LinkedIn Learning
  • Microsoft Azure DevOps (Visual Studio Team Services)
  • Portal Microsoft Azure
  • Microsoft Dynamics 365 CRM
  • Microsoft Exchange Online
  • Microsoft OneDrive for Business
  • Microsoft Power BI
  • Microsoft SharePoint Online
  • Microsoft Teams
  • Microsoft Yammer
  • Salesforce
  • ServiceNow
  • Slack
  • Tableau
  • Workday
  • Workiva
  • Tempat kerja dari Meta

Jika Anda tertarik dengan aplikasi tertentu yang telah di-onboarding sebelumnya, kirimi kami detail tentang aplikasi tersebut. Pastikan untuk mengirim kasus penggunaan yang Anda minati untuk onboarding.

Batasan umum

  • Proksi dapat dilewati menggunakan token sesi yang disematkan
    Dimungkinkan untuk melewati proksi dalam kasus di mana aplikasi itu sendiri menyematkan token dalam tautan. Pengguna akhir dapat menyalin tautan dan mengakses sumber daya secara langsung dalam kasus tersebut.

  • Kebijakan salin/potong dapat dilewati menggunakan Alat Pengembang
    Dimungkinkan untuk melewati kebijakan salin/potong yang ditentukan dengan menggunakan alat pengembang browser. Misalnya, dalam kebijakan yang mencegah salinan konten Microsoft Word, dimungkinkan untuk melihat konten menggunakan Alat Pengembang, menyalin konten dari sana lalu melewati proksi.

  • Proksi dapat dilewati oleh perubahan parameter
    Dimungkinkan untuk melewati kebijakan sesi yang ditentukan dengan memodifikasi parameter. Misalnya, dimungkinkan untuk mengubah parameter URL dan menyesatkan layanan dengan cara yang melewati proksi dan memungkinkan pengunduhan file sensitif.

  • Batasan plug-in browser
    Solusi penerapan pembatasan sesi Kontrol Aplikasi Akses Bersyarat kami saat ini tidak mendukung aplikasi asli, karena memerlukan beberapa modifikasi kode aplikasi yang mendasar. Ekstensi browser, mirip dengan aplikasi asli, telah diinstal sebelumnya di browser dan jadi jangan izinkan kami untuk memodifikasi kode mereka sesuai kebutuhan dan akan rusak ketika token mereka dialihkan melalui solusi proksi kami. Sebagai administrator, Anda dapat menentukan perilaku sistem default saat kebijakan tidak dapat diberlakukan dan memilih antara mengizinkan akses atau memblokirnya sepenuhnya.

  • Kehilangan konteks
    Dalam aplikasi berikut, kami telah menemukan skenario di mana menavigasi ke tautan dapat mengakibatkan hilangnya jalur lengkap tautan dan biasanya pengguna mendarat di halaman beranda aplikasi.

    • ArcGIS
    • GitHub
    • Microsoft Dynamics 365 CRM
    • Microsoft Power Automate
    • Microsoft Power Apps
    • Microsoft Power BI
    • Microsoft Yammer
    • Tempat kerja dari Meta
  • Kebijakan inspeksi berlaku untuk file berukuran hingga 5 MB dan 1 juta karakter

    Ketika kebijakan sesi untuk memblokir unggahan atau unduhan file berdasarkan inspeksi konten diterapkan, inspeksi dilakukan pada file yang lebih kecil dari 5 MB dan lebih kecil dari 1 juta karakter.

    Misalnya, admin dapat menentukan salah satu kebijakan sesi berikut:

    • Memblokir unggahan file untuk file yang berisi Nomor Jaminan Sosial (SSN)
    • Blokir unduhan file untuk file yang berisi PHI (Informasi Kesehatan Terproteksi) Dalam kasus seperti itu, file yang lebih besar dari 5 MB atau 1 juta karakter tidak dipindai dan diperlakukan sesuai dengan pengaturan kebijakan Selalu terapkan tindakan yang dipilih meskipun data tidak dapat dipindai.

    Berikut adalah beberapa contohnya:

    • file TXT, ukuran 1 MB, dan 1 juta karakter: akan dipindai
    • file TXT, ukuran 2 MB, dan 2 juta karakter: tidak akan dipindai
    • file Word yang terdiri dari gambar dan teks, ukuran 4 MB dan karakter 400 K: akan dipindai
    • file Word yang terdiri dari gambar dan teks, ukuran 4 MB dan 2 juta karakter: tidak akan dipindai

    Ambang ukuran file dapat dikonfigurasi hingga 50 MB (naik dari 5 MB). Dengan cara ini, dimungkinkan untuk memindai file yang berisi objek tekstual dan non-tekstual yang terdiri dari hingga 1 juta karakter.

    Alasan pembatasan adalah bahwa jumlah data yang lebih besar harus dipindai untuk mendeteksi informasi sensitif. Dalam kasus seperti itu, rekomendasi Microsoft adalah menguji kebijakan dengan jumlah pengguna terbatas lalu memperluas ke seluruh organisasi.

Langkah berikutnya

Untuk petunjuk tentang cara onboarding aplikasi Anda, lihat dokumen yang sesuai di bawah ini:

Jika Anda mengalami masalah, kami di sini untuk membantu. Untuk mendapatkan bantuan atau dukungan untuk masalah produk Anda, silakan buka tiket dukungan.