سؤالی که در جلسههای امنیتی سازمانها زیاد پرسیده میشود این است: «آیا گوگل میتواند محتوای جلسه ما را ببیند؟» جواب دقیقتر از بله و خیر است، و قابلیتی به نام Client-side encryption دقیقاً برای همین تفاوت ساخته شده.
وضعیت پیشفرض: رمزگذاری هست، ولی کلید دست شما نیست
همه جلسههای Google Meet بهصورت پیشفرض در مسیر انتقال رمزگذاری میشوند و دادههای ذخیرهشده هم رمزگذاریشده نگهداری میشوند. این یعنی کسی که ترافیک شبکه را شنود کند چیزی به دست نمیآورد. اما کلیدهای رمزگذاری در زیرساخت گوگل مدیریت میشوند؛ از نظر معماری، سرویسدهنده امکان دسترسی دارد حتی اگر سیاست سازمانیاش این کار را ممنوع کرده باشد.
برای اکثر سازمانها این سطح کافی است. برای معدودی — پیمانکار دفاعی، مؤسسه مالی با الزام انطباق خاص، پرونده حقوقی حساس — الزام قانونی میگوید کلید نباید در اختیار سرویسدهنده باشد. CSE برای همین گروه ساخته شده است.
CSE دقیقاً چه چیزی را تغییر میدهد
در رمزگذاری سمت کاربر، محتوای صوت و تصویر پیش از خروج از دستگاه شما با کلیدی رمز میشود که گوگل به آن دسترسی ندارد. آن کلید از سرویس مدیریت کلید خود سازمان گرفته میشود و هویت کاربر هم از طریق ارائهدهنده هویت (IdP) خودتان تأیید میشود. یعنی دو مؤلفه بیرون از گوگل به زنجیره اضافه میشود: سرویس کلید و سرویس هویت.
نتیجهاش این است که سرور گوگل ترافیک را عبور میدهد ولی نمیتواند رمزگشایی کند. و همینجا هزینه ماجرا شروع میشود: هر قابلیتی که برای کار کردن نیاز دارد محتوای جلسه را «بفهمد»، دیگر کار نمیکند.
چه چیزی در جلسه CSE از کار میافتد
این فهرست مهمترین بخش تصمیمگیری است و معمولاً دیرتر از موعد دیده میشود:
- زیرنویس زنده و رونوشت. برای تولید متن باید صدا پردازش شود؛ در جلسه رمزگذاریشده سمت کاربر این امکان وجود ندارد.
- قابلیتهای مبتنی بر هوش مصنوعی. خلاصه خودکار، یادداشتبرداری هوشمند و پرسش از دستیار، همه به محتوای جلسه نیاز دارند.
- بخشی از امکانات تعاملی. بسته به پیکربندی، قابلیتهایی مثل اتاق گروهی، نظرسنجی و پرسشوپاسخ ممکن است در دسترس نباشند.
- ورود مهمان بیرون از سازمان. شرکتکننده باید با هویت تأییدشده وارد شود؛ لینک دادن به مهمان دلخواه در این مدل کار نمیکند.
- پشتیبانی دستگاهها. پشتیبانی روی موبایل و سختافزار اتاق جلسه محدودتر از مرورگر دسکتاپ است.
فهرست دقیق محدودیتها را گوگل بهمرور تغییر میدهد، ولی جهت کلی ثابت است: امنیت بیشتر، قابلیت کمتر. این یک باگ نیست، پیامد مستقیم معماری است.
شرطهای فعالسازی
CSE قابلیتی نیست که کاربر با یک کلید روشن کند. حداقل چهار چیز لازم است:
- پلن مناسب. در ردههای سازمانی بالای Workspace و برخی نسخههای آموزشی در دسترس است، نه در پلنهای Business معمولی و قطعاً نه روی حساب شخصی.
- سرویس مدیریت کلید. سازمان باید با یکی از سرویسهای پشتیبانیشده مدیریت کلید یکپارچه شود.
- ارائهدهنده هویت. IdP باید پیکربندی و به Workspace متصل شود.
- فعالسازی توسط ادمین. در کنسول مدیریت، برای واحد سازمانی مشخص روشن میشود؛ میتوانید آن را فقط برای یک تیم فعال کنید نه کل سازمان.
نکته عملیاتی: بعد از فعالسازی، میزبان باید هنگام ساخت جلسه گزینه رمزگذاریشده را انتخاب کند. جلسههای موجود بهطور خودکار تبدیل نمیشوند.
آیا شما واقعاً به CSE نیاز دارید؟
قبل از رفتن سراغ این مسیر، این سه سؤال را جواب بدهید:
الزام شما قانونی است یا احساسی؟ اگر بند مشخصی در قرارداد یا مقررات صنعت شما میگوید کلید نباید دست سرویسدهنده باشد، بله. اگر فقط «حس میکنیم امنتر است»، احتمالاً هزینهاش را بیهوده میدهید.
آیا میتوانید بدون رونوشت و خلاصه کار کنید؟ برای جلسهای که تصمیمهای مهمی در آن گرفته میشود، از دست دادن رونوشت هزینه واقعی دارد. کسی باید دستی صورتجلسه بنویسد. راهنمای ثبت تصمیمها و اقدامهای بعدی جلسه نشان میدهد این کار دستی چقدر ساختار میخواهد.
مهمان بیرونی دارید؟ اگر جلسههایتان با مشتری و پیمانکار است، محدودیت هویت CSE عملاً کار را متوقف میکند.
لایههایی که قبل از CSE باید محکم شوند
در بیشتر نشتهای اطلاعاتی جلسه، مقصر رمزگذاری نیست؛ کنترل دسترسی است. لینکی که در گروه عمومی منتشر شده، مهمانی که بدون بررسی پذیرفته شده، فایل ضبطی که با دسترسی «هرکس با لینک» به اشتراک گذاشته شده. اینها را CSE حل نمیکند.
قبل از سرمایهگذاری روی رمزگذاری سمت کاربر، این سه را جدی بگیرید: کنترل ورود و پذیرش مهمان که در راهنمای Host Controls آمده، محدودیتهای پیش از جلسه مثل ارائه و چت فقط برای میزبان که در راهنمای تنظیمات اتاق در پنل آی روم توضیح داده شده، و سیاست نگهداری و اشتراک فایلهای جلسه که در ساخت آرشیو قابل جستوجوی جلسهها مطرح شده است.
اگر جلسههایتان حساس است ولی به سطح الزام CSE نمیرسد، مسیر واقعبینانهتر این است: کنترل دسترسی سختگیرانه، تفکیک فایل هر جلسه و مشخصبودن اینکه چه کسی به کدام خروجی دسترسی دارد. مدیریت فایلهای جلسه بر اساس زمان جلسه همین تفکیک را عملی میکند و برای جلسه فارسی، یادداشتبردار هوشمند خروجی قابل بازبینی میسازد — چیزی که در جلسه CSE اصلاً وجود ندارد.
خلاصه تصمیم
CSE ابزار تخصصی برای گروه کوچکی از سازمانهاست که الزام قانونی دارند. اگر جزو آن گروه نیستید، پول و پیچیدگیاش را صرف کنترل دسترسی و انضباط آرشیو کنید؛ بازدهی امنیتیاش بیشتر است و هیچ قابلیتی را هم از دست نمیدهید.
سؤالهای رایج
آیا جلسههای معمولی Google Meet رمزگذاری نمیشوند؟
میشوند. همه جلسهها در مسیر انتقال رمزگذاری میشوند و داده ذخیرهشده هم رمزگذاریشده است. تفاوت CSE این است که کلید رمز بهجای گوگل در اختیار سازمان شما قرار میگیرد.
در جلسه CSE چه قابلیتهایی کار نمیکنند؟
هر قابلیتی که برای کار کردن باید محتوای جلسه را پردازش کند: زیرنویس زنده، رونوشت، خلاصه و یادداشت هوشمند و بخشی از امکانات تعاملی. ورود مهمان بیرون از سازمان هم محدود میشود.
برای فعالسازی CSE چه چیزهایی لازم است؟
پلن سازمانی مناسب Workspace، یکپارچگی با یک سرویس مدیریت کلید، پیکربندی ارائهدهنده هویت و فعالسازی توسط ادمین برای واحد سازمانی مشخص.
آیا جلسههای موجود بهطور خودکار رمزگذاریشده میشوند؟
خیر. بعد از فعالسازی، میزبان باید هنگام ساخت جلسه گزینه رمزگذاری سمت کاربر را انتخاب کند. جلسههای قبلی تغییر نمیکنند.
اگر به CSE دسترسی نداریم، چه جایگزینی داریم؟
تمرکز روی کنترل دسترسی: پذیرش آگاهانه مهمان، بستن تنظیمات در سطح ادمین، تفکیک فایل هر جلسه و سیاست روشن اشتراکگذاری. بیشتر نشتهای واقعی از این لایهها اتفاق میافتد نه از رمزگذاری.