
Situation
Wir haben eine Web-App, die auf Amazon EC2 gehostet wird. Sie ist nur für die Verwendung durch wenige Benutzer in einem Unternehmen vorgesehen.
Wie wir damit umgehen
- Wir teilen die (Elastic-)IP-Adresse der Instanz mit den Benutzern.
- Wir fügen die IP-Adresse jedes Benutzers nach Bedarf zur Sicherheitsgruppe der Instanz hinzu.
Wenn ich sagenach Bedarf, ich meine E-Mails von Benutzern, die sich beschweren, dass das Webportal eine Fehlerseite anzeigt. Sie vergessen, dass dieser Schritt, die IP in die Sicherheitsgruppe aufzunehmen, erforderlich ist (und ich mache ihnen keine Vorwürfe, sie sind Endbenutzer).
Nehmen wir für diese Frage an, dass wir in einem Unternehmen insgesamt 5 Benutzer haben, die diesen Zugriff benötigen. Die IP-Adressen von Benutzer-1 und Benutzer-2 wurden der Sicherheitsgruppe bereits hinzugefügt.
Probleme
- Benutzer 3 geht direkt zur IP-Adresse, kann aber nicht darauf zugreifen, da die IP-Adresse des Benutzers nicht zur Sicherheitsgruppe hinzugefügt wurde.
- Wenn Benutzer 1 oder Benutzer 2 ihr Internet neu starten, ändert sich wahrscheinlich ihre IP-Adresse (dynamische IP, bereitgestellt vom ISP) und die neue IP-Adresse muss der Sicherheitsgruppe hinzugefügt werden (und die alte muss widerrufen werden, um den Zugriff durch andere zu verhindern).
Andere Optionen, die ich in Betracht ziehe
- Gewähren Sie nur Zugriff auf das VPN ihres Büros und bitten Sie alle Benutzer, sich darüber zu verbinden.
- (Sehr umständlich für den Benutzer) Bitten Sie die Benutzer, sich bei der AWS-Verwaltungskonsole anzumelden, zum EC2-Dienst zu gehen, zum Abschnitt „Sicherheitsgruppen“ zu gehen und ihre IP-Adressen manuell hinzuzufügen (die Benutzer haben bereits AWS IAM-Benutzer und die entsprechenden Berechtigungen, um dies durchzuführen).
- Erstellen Sie ein Skript, das die aktuelle IP des Benutzers zur Sicherheitsgruppe hinzufügt (mithilfe von AWS CLI/SDK) – klingt sehr gefährlich und unangemessen, da wir die API-Anmeldeinformationen einer Person in das Skript aufnehmen müssen.
Antwort1
Option 4 – Beenden Sie die Zugriffskontrolle über Sicherheitsgruppen und implementieren Sie stattdessen einen geeigneten Authentifizierungsmechanismus.
Setzen Sie beispielsweiseAnwendungslastenausgleichvor der Web-App und konfigurieren Sie den ALB so, dass erCognito-Authentifizierung. Nur authentifizierte Benutzer gelangen durch den ALB zu Ihrer Web-App – Problem gelöst. Cognito kann lokale Benutzer haben oder zusammen mit Ihrem Azure AD verwendet werden oder wenn Sie Office365 in Ihrer Organisation verwenden. Dies ist ein ziemlich transparenter Weg, der keine Änderungen an der App erfordert.
Alternativ sollten Sie, sofern Ihre Webanwendung dies unterstützt, diese so konfigurieren, dass eine SAML-Authentifizierung für das von Ihrer Organisation verwendete Benutzerverzeichnis (Office365, G-Suite usw.) erforderlich ist.
Hoffentlich hilft das :)
Antwort2
Option 5: Beenden Sie die Verwaltung von Sicherheitsgruppen (im Wesentlichen IP-basierte Firewalls) und verwenden Sie TLS-Client-Zertifikate.
Wenn Sie moderne Benutzerverwaltungssysteme wie Azure AD oder LDAP verwenden, verfügen Sie bereits über das richtige Werkzeug zum Ausstellen und Verteilen der Zertifikate. Sie richten eine private CA ein und konfigurieren den HTTP-Server (Nginx, Apache2 oder AWS ALB) so, dass er per Zertifikat authentifiziert. Wer kein Zertifikat hat oder ein ungültiges Zertifikat (auch abgelaufene) hat, kommt nicht durch den HTTP-Server. Dies erfordertnullÄndern Sie dies in der Web-App selbst. Sie können sogar die gesamte Authentifizierung in der App löschen, da Zertifikate zusätzlich zur Zugriffskontrolle auch diesen Zweck erfüllen können.
Ein Bonuspunkt ist, dass dies funktioniertüberall- sei es AWS, Azure oder Ihre lokale Infrastruktur. Sie können sogar genau denselben Stapel an Anmeldeinformationen und Konfigurationen (mit Ausnahme von AWS ALB) problemlos wiederverwenden.