Korzystanie z TLS w portalu

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Możesz skonfigurować portal tak, aby używał TLS. Procedura konfiguracji TLS dla portalu zależy od sposobu wdrożenia portalu:

• Cloud: skonfiguruj protokół TLS z Pantheon lub Acquia – działających w chmurze usług hostingu dla portalu.
• Apigee Edge dla Private Cloud: skonfiguruj lokalny protokół TLS na serwerze hostującym portal.

TLS i portal

Na ilustracji poniżej widać 2 miejsca, w których portal używa protokołu TLS:

1. Do komunikacji między portalem i interfejsem Edge Management API.
   
   Portal nie działa jako system autonomiczny. Zamiast tego znaczna część informacji używanych przez portal jest przechowywana w Edge, która umożliwia wdrożenie Edge w chmurze lub lokalnie jako instalacja w chmurze prywatnej. W razie potrzeby portal wysyła do interfejsu Edge Management API żądanie HTTP lub HTTPS, aby je pobrać lub wysłać.
   
   Jedną z pierwszych czynności, które musisz wykonać podczas tworzenia portalu, jest określenie adresu URL interfejsu Edge Management API. W zależności od konfiguracji interfejsu Edge Management API dla danego adresu URL może być używany protokół TLS. Więcej informacji znajdziesz w artykule na temat tworzenia portalu dla programistów.
2. Do komunikacji między deweloperami a portalem.
   
   Gdy wdrażasz interfejsy API w portalu usług dla programistów, deweloperzy logują się w nim, aby zarejestrować aplikacje i otrzymywać klucze interfejsu API. Dane logowania i klucz interfejsu API to zastrzeżone informacje, które chcesz przesłać za pomocą protokołu HTTPS, aby zapewnić ich bezpieczeństwo. Ten typ zastrzeżonych informacji należy przesyłać za pomocą protokołu HTTPS.
   
   Sposób konfigurowania TLS w tym scenariuszu zależy od sposobu wdrożenia portalu: Cloud lub Apigee Edge dla Private Cloud. W sekcjach poniżej opisano oba scenariusze.

Konfigurowanie protokołu TLS między portalem a interfejsem API do zarządzania Edge

Konfiguracja interfejsu Edge Management API określa, czy komunikacja może korzystać z TLS. Jeśli interfejs Edge Management API jest skonfigurowany pod kątem używania TLS, portal może używać HTTPS. W przeciwnym razie portal będzie komunikować się z Edge przez HTTP. Dlatego jako programista portalu musisz tylko wiedzieć, jak skonfigurowano Edge w celu ustawienia połączenia między portalem a Edge.

Instrukcje konfigurowania połączenia z interfejsem Edge Management API znajdziesz w artykule o tworzeniu portalu dla programistów.

Działająca w chmurze wersja Edge

Jeśli Twój portal łączy się z wersją Edge działającą w chmurze, adres URL interfejsu Edge Management API jest wstępnie skonfigurowany przez Apigee pod kątem używania TLS. Podczas konfigurowania portalu uzyskujesz dostęp do interfejsu Edge Management API pod adresem URL https://api.enterprise.apigee.com/v1.

Instalacja Edge w chmurze prywatnej

W przypadku instalacji Edge w Private Cloud adres URL interfejsu Edge Management API ma postać:
http://EdgePrivateCloudIp:8080/v1
lub:
https://EdgePrivateCloudIp:TLSport/v1

gdzie EdgePrivateCloudIp to adres IP serwera zarządzania brzegiem, a TLSport to port TLS interfejsu API zarządzania brzegiem. Na przykład numer portu może wynosić 8443, a nawet 8080, zależnie od konfiguracji brzegowej.

Konfigurowanie protokołu TLS między deweloperami a portalem

Sposób konfigurowania protokołu TLS między deweloperami a portalem zależy od sposobu wdrożenia portalu: w chmurze lub Apigee Edge dla Private Cloud.

Portale działające w chmurze

Panteon

Pantheon udostępnia bezpłatny, automatyczny protokół HTTPS dla wszystkich witryn na swojej platformie za pomocą globalnej sieci CDN Pantheon i korzystając z Let's Encrypt. Zobacz też HTTPS w globalnej sieci CDN firmy Pantheon.

Acquia

Aby włączyć TLS/SSL w Acquia, zobacz Włączanie SSL.

Edge dla portali w chmurze prywatnej

Wszystkie zalecane instalacje Apigee w chmurze prywatnej portalu wymagają, aby portal znajdował się za systemem równoważenia obciążenia, jak w tym przykładzie:

Dlatego w przypadku instalacji lokalnych dostępne są 2 opcje konfigurowania protokołu TLS:

• Skonfiguruj TLS w systemie równoważenia obciążenia: skonfiguruj TLS w samym systemie równoważenia obciążenia, a nie w portalu. Procedura, której używasz do konfigurowania protokołu TLS, zależy od systemu równoważenia obciążenia. Więcej informacji znajdziesz w dokumentacji systemu równoważenia obciążenia.
• Skonfiguruj protokół TLS w portalu: w razie potrzeby możesz skonfigurować protokół TLS na serwerze WWW hostującym portal. Więcej informacji znajdziesz w artykule o konfigurowaniu portalu do używania protokołu HTTPS.

Przed wdrożeniem portalu w środowisku produkcyjnym musisz uzyskać własny certyfikat TLS.

Konfigurowanie dodatkowych ustawień TLS

Możesz edytować plik sites/default/settings.local.php (chmura) lub sites/default/settings.php (Private Cloud), aby wprowadzić zmiany w konfiguracji TLS portalu.

Podczas edycji pliku dodaj wystąpienia funkcji ini_set(), aby ustawić właściwość. Więcej informacji na temat tej funkcji znajdziesz na stronie http://php.net/manual/en/function.ini-set.php.

W pliku sites/default/settings.local.php (chmura) lub sites/default/settings.php (Private Cloud) możesz ustawić te właściwości:

• cookie_httponly: (zalecane) określa ten plik cookie jako dostępny tylko przez protokół HTTP. Ustaw tę właściwość jako:
  
  ini_set('session.cookie_httponly', true);
• session.cookie_secure – (opcjonalne) określa, że pliki cookie mogą być wysyłane tylko przez bezpieczne połączenia. Oznacza to jednak, że cała zawartość musi być wyświetlana przy użyciu protokołu HTTPS. Jeśli to ustawienie jest włączone, witryna nie obsługuje protokołu HTTP. Ustaw tę właściwość jako:
  
  ini_set('session.cookie_secure', true);
• gc_maxlifetime i cookie_lifetime: (opcjonalnie) gc_lifeteime określa liczbę sekund, po których dane można potencjalnie wyczyścić, a cookie_lifetime określa czas życia pliku cookie w sekundach. Ustaw te właściwości jako:
  
  ini_set('session.gc_maxlifetime', 3600);
  ini_set('session.cookie_lifetime', 3600);

Więcej informacji o konfigurowaniu protokołu TLS między portalem dla programistów a klientami znajdziesz w artykule Włączanie SSL dla bezpiecznej komunikacji HTTPS w witrynie dokumentacji Pantheon.

Konfigurowanie protokołu TLS z systemami równoważenia obciążenia

Aby zapewnić lepszą wydajność, systemy równoważenia obciążenia są czasami skonfigurowane tak, aby przeprowadzały zakończenie TLS. W przypadku zakończenia obsługi TLS systemy równoważenia obciążenia odszyfrowują wiadomości wysyłane przez https:// i przekierowują je na serwery backendu przez http://. Dzięki temu serwery backendu nie muszą poświęcać czasu na odszyfrowywanie wiadomości https://.

Jeśli systemy równoważenia obciążenia przekazują niezaszyfrowane wiadomości HTTP do serwerów w tym samym centrum danych, zabezpieczenia nie są problemem. Jeśli jednak systemy równoważenia obciążenia przekazują wiadomości przez http:// do serwerów poza centrum danych, na przykład do portalu dla programistów Apigee, wiadomości nie są szyfrowane, co stanowi lukę w zabezpieczeniach.

Jeśli Twój portal dla programistów znajduje się za systemami równoważenia obciążenia używającymi zakończenia TLS i chcesz, aby cały ruch odbywał się przez https://, strony witryny muszą zawierać tylko linki https://. Musisz też dodać ten kod do pliku w portalu dla programistów sites/default/settings.local.php (w chmurze) lub sites/default/settings.php (Private Cloud). System równoważenia obciążenia nie przekształca automatycznie treści stron HTML, dlatego kod daje pewność, że wszystkie linki przekazywane do klienta zaczynają się od https://.

Aby skonfigurować protokół TLS z systemami równoważenia obciążenia, dodaj następujące wiersze do pliku sites/default/settings.local.php (chmura) lub sites/default/settings.php (Private Cloud):

// Only check for SSL if we are not using PHP from the command line.
if (PHP_SAPI != 'cli') {
  // Assume we can't detect SSL unless proven otherwise.
  $can_detect_ssl = FALSE;

  // Set HTTPS URL of portal 
  $base_url = 'https://developers.myCo.com';

  if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) || (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on')) {
    $can_detect_ssl = TRUE;
  }

  if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https') {
    $_SERVER['HTTPS'] = 'on';
  }

  if ($can_detect_ssl && $_SERVER['HTTPS'] != 'on') {
    header('HTTP/1.0 301 Moved Permanently');
    // You could optionally substitute a canonical server name for $_SERVER['HTTP_HOST'] here.
    header('Location: https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
    exit;
  }
}

Aby dowiedzieć się więcej, zobacz:

• https://drupal.org/node/425990
• https://drupal.org/node/313145
• http://drupal.stackexchange.com/questions/102091/drupal-behind-a-ssl-offloading-reverse-proxy-is-this-config-correct

Przekierowuję ruch w portalu do protokołu HTTPS

Aby przekierować cały ruch w portalu do HTTPS, możesz zaktualizować plik sites/default/settings.local.php (w chmurze) lub sites/default/settings.php (Private Cloud). Wymagane aktualizacje różnią się w zależności od tego, czy przekierowujesz do HTTPS z tej samej nazwy hosta czy z wieloma nazwami.

Przekierowanie do HTTPS na tym samym hoście

Dodaj ten kod do pliku sites/default/settings.local.php (chmura) lub sites/default/settings.php (Private Cloud), aby przekierowywać ruch do protokołu HTTPS z tego samego hosta (na przykład *.devportal.apigee.io).

W tym scenariuszu, jeśli deweloper odwiedza Twój portal pod adresem live-example.devportal.apigee.io, ale potrzebuje dostępu do certyfikatu przesłanego dla devportal.example.com, żądanie nie powiedzie się.

// Only check for SSL if we are not using PHP from the command line.
if (PHP_SAPI != 'cli') {
  // Assume we can't detect SSL unless proven otherwise.
  $can_detect_ssl = FALSE;

  if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) || (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on')) {
    $can_detect_ssl = TRUE;
  }

  if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https') {
    $_SERVER['HTTPS'] = 'on';
  }

  if ($can_detect_ssl && $_SERVER['HTTPS'] != 'on') {
    header('HTTP/1.0 301 Moved Permanently');
    header('Location: https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
    exit;
  }
}

Przekierowanie do HTTPS w przypadku wielu nazw hostów

Dodaj ten kod do pliku sites/default/settings.local.php (w chmurze) lub sites/default/settings.php (Private Cloud), aby przekierowywać ruch z portalu do HTTPS na różnych hostach.

  // Only check for SSL if we are not using PHP from the command line.
if (PHP_SAPI != 'cli') {
  // Assume we can't detect SSL unless proven otherwise.
  $can_detect_ssl = FALSE;
  // Assume we are not forcing a redirect until proven otherwise.
  $force_redirect = FALSE;

  if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) || (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on')) {
    $can_detect_ssl = TRUE;
  }

  if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https') {
    $_SERVER['HTTPS'] = 'on';
  }
  
  if ($can_detect_ssl && $_SERVER['HTTPS'] != 'on') {
    // We will force a redirect because HTTPS is required.
    $force_redirect = TRUE;
  }
  
  // This works on Pantheon only; the constant is undefined elsewhere.
  switch (PANTHEON_ENVIRONMENT) {
    case 'dev':
      $canonical_hostname = 'dev.devportal.example.com';
      break;
    case 'test':
      $canonical_hostname = 'test.devportal.example.com';
      break;
    case 'live':
      $canonical_hostname = 'devportal.example.com';
      break;
    default:
      $canonical_hostname = strtolower($_SERVER['HTTP_HOST']);
      break;
  }
  if ($canonical_hostname != strtolower($_SERVER['HTTP_HOST'])) {
    // We will force a redirect because hostname is not canonical.
    $force_redirect = TRUE;
  }

  if ($force_redirect) {
    header('HTTP/1.0 301 Moved Permanently');
    header('Location: https://' . $canonical_hostname . $_SERVER['REQUEST_URI']);
    exit;
  }
}