احراز هویت و مجوز

این بخش مفاهیم احراز هویت و مجوز را با توجه به پیاده سازی Fleet Engine توضیح می دهد. این جزئیات رویه‌هایی را که باید برای ایمن کردن تماس‌های عملکرد Fleet Engine خود انجام دهید، توضیح می‌دهد.

می‌توانید قابلیت‌های ارائه شده توسط Last Mile Fleet Solution را از طریق Google Cloud Console پیکربندی کنید. این APIها و SDKها به استفاده از رمزهای وب JSON (JWT) نیاز دارند که با استفاده از حساب‌های سرویس ایجاد شده از کنسول Cloud امضا شده‌اند.

بررسی اجمالی

Fleet Engine به عنوان بخشی از مکانیسم مجوز خود، امنیت بیشتری را از تماس‌هایی که از محیط‌های کم‌اعتماد سرچشمه می‌گیرند، فراهم می‌کند. محیط های کم اعتماد شامل گوشی های هوشمند و مرورگرها هستند. علاوه بر این، Fleet Engine از اصل حداقل امتیاز استفاده می‌کند، که در آن یک تماس باید تنها امتیازاتی را که برای تکمیل وظیفه‌اش لازم است داده شود.

برای محافظت از تماس‌های تابعی که از محیط‌های کم‌اعتماد سرچشمه می‌گیرند، Google مکانیزمی را طراحی کرده است که در آن کد شما یک توکن در سرور پشتیبان شما ایجاد می‌کند که یک محیط کاملاً قابل اعتماد است. هر تماس حاوی یک توصیف امنیتی کامل است که سپس در یک JWT رمزگذاری می شود که با تماس از هر محیطی ارسال می کنید.

اصول طراحی احراز هویت

جریان احراز هویت Fleet Engine اصول طراحی زیر را در بر می گیرد.

  • نقش های IAM محدوده فعالیت مجاز را برای تماس گیرنده تعریف می کنند. به عنوان مثال، نقش SuperUser مجاز به انجام همه کارها است، در حالی که نقش راننده غیرقابل اعتماد فقط مجاز است حداقل به روز رسانی مکان را انجام دهد.

  • نقش های IAM با حساب های خدمات مرتبط هستند.

  • ادعاهای JWT بیشتر نهادهایی را که تماس گیرنده ممکن است روی آنها کار کند محدود می کند. اینها می توانند وظایف خاص یا وسایل نقلیه تحویل باشند.

  • درخواست های ارسال شده به Fleet Engine همیشه حاوی JWT هستند.

    • از آنجایی که JWT ها با حساب های خدمات مرتبط هستند، درخواست های ارسال شده به Fleet Engine به طور ضمنی با حساب سرویس مرتبط با JWT مرتبط است.
  • برای درخواست JWT مناسب که می‌توانید آن را به Fleet Engine ارسال کنید، کدی که در یک محیط کم‌اعتماد اجرا می‌شود، ابتدا باید کد شما را که در یک محیط کاملاً مطمئن اجرا می‌شود فراخوانی کند.

  • Fleet Engine بررسی های امنیتی زیر را انجام می دهد:

    1. نقش‌های IAM مرتبط با حساب سرویس، مجوز صحیحی را برای تماس‌گیرنده برای صدور تماس API فراهم می‌کنند.

    2. ادعاهای JWT ارائه شده در درخواست، مجوز صحیحی را برای تماس گیرنده برای فعالیت در نهاد ارائه می دهد.

جریان احراز هویت

نمودار توالی زیر این جزئیات جریان احراز هویت را نشان می دهد.

  1. مدیر ناوگان حساب های خدماتی ایجاد می کند.

  2. مدیر ناوگان نقش های خاص IAM را به حساب های خدمات اختصاص می دهد.

  3. مدیر ناوگان پشتیبان آنها را با حساب های سرویس پیکربندی می کند.

  4. برنامه مشتری یک JWT از باطن شریک درخواست می کند. درخواست کننده می تواند برنامه Driver، برنامه Consumer یا یک برنامه نظارت باشد.

  5. Fleet Engine یک JWT برای حساب سرویس مربوطه صادر می کند. برنامه مشتری JWT را دریافت می کند.

  6. برنامه مشتری از JWT برای اتصال به Fleet Engine برای خواندن یا اصلاح داده ها استفاده می کند، بسته به نقش های IAM که در مرحله راه اندازی به آن اختصاص داده شده است.

نمودار توالی احراز هویت

راه اندازی پروژه ابری

برای راه اندازی پروژه ابری خود، ابتدا پروژه خود را ایجاد کنید و سپس حساب های خدماتی ایجاد کنید.

برای ایجاد پروژه Google Cloud:

  1. با استفاده از Google Cloud Console یک پروژه Google Cloud ایجاد کنید.
  2. با استفاده از API ها و داشبورد خدمات، API Local Rides and Deliveries را فعال کنید.

حساب‌های خدمات و نقش‌های IAM

حساب سرویس نوع خاصی از حساب است که به جای یک شخص، توسط یک برنامه کاربردی استفاده می شود. به طور معمول، یک حساب سرویس برای برش JWT استفاده می شود که بسته به نقش مجموعه های مختلفی از مجوزها را می دهد. برای کاهش احتمال سوء استفاده، می توانید چندین حساب سرویس ایجاد کنید که هر کدام دارای حداقل مجموعه ای از نقش های مورد نیاز هستند.

Last Mile Fleet Solution از نقش های زیر استفاده می کند:

نقش شرح
کاربر راننده قابل اعتماد تحویل موتور ناوگان

roles/fleetengine.deliveryTrustedDriver
اجازه ایجاد و به‌روزرسانی وسایل نقلیه و وظایف تحویل، از جمله به‌روزرسانی مکان وسیله نقلیه تحویلی و وضعیت یا نتیجه کار را می‌دهد. توکن‌هایی که توسط یک حساب سرویس با این نقش ایجاد می‌شوند، معمولاً از دستگاه‌های تلفن همراه راننده تحویل شما یا از سرورهای پشتیبان شما استفاده می‌شوند.
کاربر راننده غیرقابل اعتماد تحویل موتور ناوگان

roles/fleetengine.deliveryUntrustedDriver
اجازه به‌روزرسانی مکان خودروی تحویل را می‌دهد. توکن‌هایی که توسط یک حساب سرویس با این نقش ایجاد می‌شوند، معمولاً از دستگاه‌های تلفن همراه راننده تحویل شما استفاده می‌شوند.
کاربر مصرف کننده تحویل موتور ناوگان

roles/fleetengine.deliveryConsumer
به جستجوی کارها با استفاده از شناسه ردیابی و خواندن اما عدم به‌روزرسانی اطلاعات کار اجازه می‌دهد. توکن‌هایی که توسط یک حساب سرویس با این نقش ایجاد می‌شوند، معمولاً از مرورگر وب مصرف‌کننده تحویل استفاده می‌شوند.
کاربر فوق العاده تحویل موتور ناوگان

roles/fleetengine.deliverySuperUser
به همه وسایل نقلیه تحویل و APIهای وظایف مجوز می دهد. توکن‌هایی که توسط یک حساب سرویس با این نقش ایجاد می‌شوند، معمولاً از سرورهای پشتیبان شما استفاده می‌شوند.
Fleet Engine Delivery Fleet Reader

roles/fleetengine.deliveryFleetReader
به خواندن وسایل نقلیه تحویلی و وظایف و جستجوی کارها با استفاده از شناسه ردیابی اجازه می دهد. توکن‌هایی که توسط یک حساب سرویس با این نقش ساخته می‌شوند، معمولاً از مرورگر وب اپراتور ناوگان تحویل استفاده می‌شوند.

سازمان‌هایی که درایورهای تحویل خود را با دستگاه‌هایی که توسط فناوری اطلاعات شرکت مدیریت می‌شوند تجهیز می‌کنند، می‌توانند از انعطاف‌پذیری ارائه شده توسط نقش کاربر راننده معتمد Fleet Engine استفاده کنند و برخی یا همه تعاملات Fleet Engine را در برنامه تلفن همراه ادغام کنند.

سازمان‌هایی که از خط‌مشی‌های Bring Your Own Device حمایت می‌کنند باید ایمنی نقش کاربر راننده نامعتبر موتور ناوگان را انتخاب کنند و برای ارسال به‌روزرسانی‌های مکان وسیله نقلیه به Fleet Engine فقط به برنامه تلفن همراه تکیه کنند. تمام تعاملات دیگر باید از سرورهای پشتیبان مشتری سرچشمه بگیرد.

Driver و Consumer SDK بر اساس این نقش های استاندارد ساخته شده اند. با این حال، می‌توان نقش‌های سفارشی ایجاد کرد که اجازه می‌دهد مجموعه‌ای دلخواه از مجوزها با هم جمع شوند. Driver و Consumer SDK پیغام های خطا را در صورت عدم وجود مجوز مورد نیاز نمایش می دهند. در نتیجه، ما قویاً توصیه می کنیم از مجموعه استاندارد نقش های ارائه شده در بالا به جای نقش های سفارشی استفاده کنید.

ایجاد یک حساب خدمات

می‌توانید با استفاده از تب IAM & Admin > Service Accounts در Google Cloud Console یک حساب سرویس ایجاد کنید. از لیست کشویی Role، Fleet Engine را انتخاب کرده و یکی از نقش ها را به حساب سرویس اختصاص دهید. نشان دادن حسابی که با هر نقش مرتبط است، تمرین خوبی است. به عنوان مثال، به حساب سرویس یک نام معنادار بدهید.

برای راحتی، اگر نیاز دارید JWTها را برای مشتریان غیرقابل اعتماد برش دهید، افزودن کاربران به نقش ایجاد کننده رمز حساب سرویس به آنها امکان می دهد توکن ها را با ابزارهای خط فرمان gcloud برش دهند.

gcloud projects add-iam-policy-binding project-id \
       --member=user:my-user@example.com \
       --role=roles/iam.serviceAccountTokenCreator

جایی که my-user@example.com ایمیلی است که برای احراز هویت با gcloud استفاده می‌شود ( gcloud auth list --format='value(account)' ).

کتابخانه تأیید موتور ناوگان

Fleet Engine از JWTها برای محدود کردن دسترسی به APIهای Fleet Engine استفاده می کند. کتابخانه جدید Fleet Engine Auth که در Github موجود است ، ساخت JWTهای Fleet Engine را ساده کرده و آنها را به صورت ایمن امضا می کند.

این کتابخانه دارای مزایای زیر است:

  • فرآیند ایجاد توکن های Fleet Engine را ساده می کند.
  • مکانیسم‌های امضای رمز را به غیر از استفاده از فایل‌های اعتبار (مانند جعل هویت یک حساب سرویس) ارائه می‌کند.
  • توکن‌های امضا شده را به درخواست‌های خروجی که از یک کاربر خرد gRPC یا GAPIC ارسال شده است، پیوست می‌کند.

ایجاد یک توکن وب JSON (JWT) برای مجوز

هنگامی که از کتابخانه تأیید Fleet Engine استفاده نمی کنید، JWT ها باید مستقیماً در پایگاه کد شما ایجاد شوند. این امر مستلزم آن است که هم درک عمیقی از JWT ها و هم ارتباط آنها با Fleet Engine داشته باشید. به همین دلیل است که ما به شدت توصیه می کنیم از کتابخانه تأیید موتور ناوگان استفاده کنید.

در Fleet Engine، JWT ها احراز هویت کوتاه مدت را ارائه می کنند و اطمینان می دهند که دستگاه ها فقط می توانند وسایل نقلیه یا کارهایی را که برای آنها مجاز هستند تغییر دهند. JWT ها شامل یک هدر و یک بخش ادعا هستند. بخش هدر حاوی اطلاعاتی مانند کلید خصوصی برای استفاده (به دست آمده از حساب های سرویس) و الگوریتم رمزگذاری است. بخش ادعا حاوی اطلاعاتی مانند زمان ایجاد توکن، زمان زنده ماندن توکن، خدماتی است که توکن ادعای دسترسی به آنها را دارد و سایر اطلاعات مجوز برای محدود کردن دسترسی. به عنوان مثال، شناسه وسیله نقلیه تحویل.

یک بخش هدر JWT شامل فیلدهای زیر است:

رشته شرح
alg الگوریتم مورد استفاده "RS256".
تایپ کنید نوع توکن "JWT".
بچه شناسه کلید خصوصی حساب سرویس شما. می‌توانید این مقدار را در قسمت «private_key_id» فایل JSON حساب سرویس خود بیابید. اطمینان حاصل کنید که از یک کلید از یک حساب سرویس با سطح صحیح مجوز استفاده می کنید.

بخش ادعاهای JWT شامل فیلدهای زیر است:

رشته شرح
iss آدرس ایمیل حساب سرویس شما.
زیر آدرس ایمیل حساب سرویس شما.
aud SERVICE_NAME حساب سرویس شما، در این مورد https://fleetengine.googleapis.com/
iat مُهر زمانی که نشانه ایجاد شد، برحسب ثانیه های سپری شده از ساعت 00:00:00 UTC، 1 ژانویه 1970 مشخص شده است. برای انحراف 10 دقیقه زمان بگذارید. اگر مهر زمانی در گذشته یا در آینده خیلی دور باشد، سرور ممکن است خطا را گزارش کند.
انقضا مهر زمانی که نشان منقضی می‌شود، برحسب ثانیه مشخص شده است که از ساعت 00:00:00 UTC، 1 ژانویه 1970 سپری شده است. اگر مهر زمانی بیش از یک ساعت در آینده باشد، درخواست انجام نمی‌شود.
مجوز بسته به مورد استفاده، ممکن است حاوی «deliveryvehicleid»، «trackingid»، «taskid» یا «taskids» باشد.

ضرب کردن یک توکن JWT به امضای آن اشاره دارد. برای دستورالعمل‌ها و نمونه‌های کد برای ایجاد و امضای JWT، به مجوز حساب سرویس بدون OAuth مراجعه کنید. سپس می توانید یک توکن ضرب شده را به تماس های gRPC یا سایر روش های مورد استفاده برای دسترسی به Fleet Engine متصل کنید.

ادعاهای JWT

Last Mile Fleet Solution از ادعاهای خصوصی استفاده می کند. استفاده از ادعاهای خصوصی تضمین می کند که فقط مشتریان مجاز می توانند به داده های خود دسترسی داشته باشند. به عنوان مثال، هنگامی که باطن شما یک رمز وب JSON برای دستگاه تلفن همراه راننده تحویل صادر می کند، آن رمز باید حاوی ادعای deliveryvehicleid با مقدار شناسه وسیله نقلیه تحویل راننده باشد. سپس، بسته به نقش راننده، توکن‌ها دسترسی را فقط برای شناسه وسیله نقلیه تحویل خاص و نه هر شناسه خودرو دلخواه دیگر را امکان‌پذیر می‌کنند.

Last Mile Fleet Solution از ادعاهای خصوصی زیر استفاده می کند:

  • deliveryvehicleid - هنگام فراخوانی APIهای هر تحویل خودرو استفاده کنید.
  • taskid - هنگام فراخوانی APIهای هر وظیفه استفاده کنید.
  • taskids - هنگام فراخوانی BatchCreateTasksAPI استفاده کنید. این ادعا باید به صورت آرایه باشد و آرایه باید شامل تمام شناسه های وظیفه لازم برای تکمیل درخواست باشد. ادعاهای delivervehicleid ، trackingid یا taskid را شامل نشود.
  • trackingid - هنگام فراخوانی SearchTasksAPI استفاده کنید. ادعا باید با شناسه پیگیری در درخواست مطابقت داشته باشد. ادعاهای delivervehicleid ، taskid یا taskids را شامل نشود.

هنگام فراخوانی APIها از سرور پشتیبان خود، توکن باید حاوی ادعای مناسب نیز باشد، اما می‌توانید از مقدار ویژه یک ستاره ("*") برای ادعاهای deliveryvehicleid ، taskid و trackingid استفاده کنید. ستاره ("*") همچنین ممکن است در ادعای taskids استفاده شود، اما باید تنها عنصر در آرایه باشد.

اگر می‌خواهید به‌جای استفاده از نشانه‌های دسترسی OAuth 2.0، یک JSON را مستقیماً به‌عنوان حامل نشانه ایجاد و امضا کنید، دستورالعمل‌های مجوز حساب سرویس بدون OAuth را در مستندات Identity Developer بخوانید.

مکانیسم اتصال توکن به فراخوانی gRPC به زبان و چارچوب مورد استفاده برای برقراری تماس بستگی دارد. همانطور که در یادداشت‌های مجوز برای ردیابی محموله‌ها یا موارد استفاده عملکرد ناوگان ذکر شده است، مکانیسم تعیین یک توکن برای تماس HTTP شامل یک سرصفحه مجوز با یک توکن حامل است که ارزش آن توکن است.

مثال زیر یک نشانه برای عملیات هر وظیفه از سرور باطن شما نشان می دهد:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "taskid": "*"
       }
    }

مثال زیر یک نشانه برای عملیات ایجاد دسته ای وظایف از سرور باطن شما را نشان می دهد:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "taskids": ["*"]
       }
    }

مثال زیر یک نشانه برای عملیات هر تحویل خودرو از سرور پشتیبان شما نشان می دهد:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "deliveryvehicleid": "*"
       }
    }

مثال زیر یک توکن را برای مشتریان کاربر نهایی نشان می دهد:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_delivery_consumer_service_account"
    }
    .
    {
      "iss": "consumer@yourgcpproject.iam.gserviceaccount.com",
      "sub": "consumer@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "trackingid": "shipment_12345"
       }
    }

مثال زیر یک نشانه برای برنامه درایور شما نشان می دهد:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_delivery_driver_service_account"
    }
    .
    {
      "iss": "driver@yourgcpproject.iam.gserviceaccount.com",
      "sub": "driver@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "deliveryvehicleid": "driver_12345"
       }
    }
  • برای فیلد kid در هدر، شناسه کلید خصوصی حساب سرویس خود را مشخص کنید. می توانید این مقدار را در قسمت private_key_id فایل JSON حساب سرویس خود بیابید.
  • برای فیلدهای iss و sub ، آدرس ایمیل حساب سرویس خود را مشخص کنید. می توانید این مقدار را در قسمت client_email فایل JSON حساب سرویس خود بیابید.
  • برای قسمت aud ، https://SERVICE_NAME/ را مشخص کنید.
  • برای فیلد iat ، مهر زمانی را که نشانه ایجاد شد، بر حسب ثانیه های سپری شده از ساعت 00:00:00 UTC، 1 ژانویه 1970 مشخص کنید. 10 دقیقه برای چولگی در نظر گرفته شود. اگر مهر زمانی در گذشته یا در آینده خیلی دور باشد، سرور ممکن است خطا را گزارش کند.
  • برای فیلد exp ، زمان انقضای رمز را برحسب ثانیه از ساعت 00:00:00 UTC، 1 ژانویه 1970 مشخص کنید. مقدار توصیه شده iat + 3600 است.

هنگام امضای توکن برای ارسال به یک دستگاه تلفن همراه یا کاربر نهایی، مطمئن شوید که از فایل اعتبارنامه برای نقش راننده تحویل یا مصرف کننده استفاده می کنید. در غیر این صورت، دستگاه تلفن همراه یا کاربر نهایی این امکان را خواهند داشت که اطلاعاتی را که نباید به آنها دسترسی داشته باشند، تغییر داده یا مشاهده کنند.