閉める
閉める
明日に向けたネットワーク
明日に向けたネットワーク
サポートするアプリケーションとユーザー向けに設計された、より高速で、より安全で、回復力のあるネットワークへの道を計画します。
          Netskopeを体験しませんか?
          Netskopeプラットフォームを実際に体験する
          Netskope Oneのシングルクラウドプラットフォームを直接体験するチャンスです。自分のペースで進められるハンズオンラボにサインアップしたり、毎月のライブ製品デモに参加したり、Netskope Private Accessの無料試乗に参加したり、インストラクター主導のライブワークショップに参加したりできます。
            SSEのリーダー。 現在、シングルベンダーSASEのリーダーです。
            SSEのリーダー。 現在、シングルベンダーSASEのリーダーです。
            Netskope、2024年ガートナー、シングルベンダーSASEのマジック・クアドラントでリーダーの1社の位置付けと評価された理由をご確認ください。
              ダミーのためのジェネレーティブAIの保護
              ダミーのためのジェネレーティブAIの保護
              ジェネレーティブ AI の革新的な可能性と堅牢なデータ セキュリティ プラクティスのバランスを取る方法をご覧ください。
                ダミーのための最新のデータ損失防止(DLP)eBook
                最新の情報漏えい対策(DLP)for Dummies
                クラウド配信型 DLP に移行するためのヒントとコツをご紹介します。
                  SASEダミーのための最新のSD-WAN ブック
                  SASEダミーのための最新のSD-WAN
                  遊ぶのをやめる ネットワークアーキテクチャに追いつく
                    リスクがどこにあるかを理解する
                    Advanced Analytics は、セキュリティ運用チームがデータ主導のインサイトを適用してより優れたポリシーを実装する方法を変革します。 Advanced Analyticsを使用すると、傾向を特定し、懸念事項に的を絞って、データを使用してアクションを実行できます。
                        レガシーVPNを完全に置き換えるための6つの最も説得力のあるユースケース
                        レガシーVPNを完全に置き換えるための6つの最も説得力のあるユースケース
                        Netskope One Private Accessは、VPNを永久に廃止できる唯一のソリューションです。
                          Colgate-Palmoliveは、スマートで適応性のあるデータ保護により「知的財産」を保護します
                          Colgate-Palmoliveは、スマートで適応性のあるデータ保護により「知的財産」を保護します
                            Netskope GovCloud
                            NetskopeがFedRAMPの高認証を達成
                            政府機関の変革を加速するには、Netskope GovCloud を選択してください。
                              一緒に素晴らしいことをしましょう
                              Netskopeのパートナー中心の市場開拓戦略により、パートナーは企業のセキュリティを変革しながら、成長と収益性を最大化できます。
                                Netskopeソリューション
                                Netskope Cloud Exchange
                                Netskope Cloud Exchange(CE)は、セキュリティ体制全体で投資を活用するための強力な統合ツールをお客様に提供します。
                                  Netskopeテクニカルサポート
                                  Netskopeテクニカルサポート
                                  クラウドセキュリティ、ネットワーキング、仮想化、コンテンツ配信、ソフトウェア開発など、多様なバックグラウンドを持つ全世界にいる有資格のサポートエンジニアが、タイムリーで質の高い技術支援を行っています。
                                    Netskopeの動画
                                    Netskopeトレーニング
                                    Netskopeのトレーニングは、クラウドセキュリティのエキスパートになるためのステップアップに活用できます。Netskopeは、お客様のデジタルトランスフォーメーションの取り組みにおける安全確保、そしてクラウド、Web、プライベートアプリケーションを最大限に活用するためのお手伝いをいたします。

                                      Leaving Bastion Hosts Behind Part 3: Azure

                                      Sep 09 2020

                                      This post is the third in a series about alternatives to bastion hosts in each of the major cloud providers. The first post covered an introduction to bastion hosts, the SSH multiplexing attack, some disadvantages to managing your own bastions, and an alternative solution in GCP. The second post covered the Session Manager service provided by AWS. This post will cover the Azure Bastion service, which is a very good choice for providing management access, although it doesn’t quite address all of our requirements.

                                      The requirements it did satisfy:

                                      • Does not require public IP addresses for the VMs.
                                      • Eliminates the possibility of SSH multiplexing attacks.
                                      • Captures metadata and full session logs (when possible) for remote access.

                                      The requirement it did not satisfy is:

                                      • Consolidates access (such as SSH or RDP) to IAM credentials.

                                      Although the initial access to the bastion is authorized via IAM credentials, you still need to maintain SSH certificates in order to access your virtual machines from the bastion. 

                                      While the Azure Bastion service supports Linux and Windows instances, we will focus on using it with Linux-based virtual machines running in an Azure Virtual Network.

                                      Why Azure Bastion service?

                                      The bastion service provides the following features that make it a good fit for our purposes:

                                      • Allows admins to monitor and disconnect active sessions
                                      • Captures metadata about sessions very easily in audit logs

                                      Azure Bastion instances can be used to access virtual machines within private subnets that allow no ingress from the internet. However, the virtual machines must allow SSH ingress from the bastion subnet. Unfortunately, the bastion service does not currently support just-in-time access or Active Directory integration, although these features are on the roadmap.

                                      The figure below, which was taken from Azure documentation, shows that the virtual machines are not at all accessible from the internet, even by our enterprise user. The user accesses the Azure portal to start a session over HTTPS with the bastion instance. Once that’s been established, the user can then use the bastion to connect to the target virtual machine(s) over SSH.

                                      Now that you have an idea of how the Azure Bastion service works in general, we’ll take a closer look at it by breaking down the details into the following categories:

                                      1. Networking Considerations
                                      2. Virtual Machine Configuration
                                      3. Identity Management
                                      4. Logging

                                      Networking Considerations

                                      Create the bastion

                                      In order to use the Azure Bastion service for access, you must first create a subnet called, “AzureBastionSubnet.” This is the name it must be given according to the documentation found here.

                                      Once you have created the subnet, you can create a bastion instance within that subnet. An external IP address will be assigned to the bastion for you. There is no need to assign a Network Security Group (NSG), or set any firewall rules on the bastion instance.

                                      Setting the NSG rules

                                      By default, there is no network security group (NSG) assigned to the bastion host. The recommendations for NSG rules associated with the bastion hosts and virtual machines are available here. We implemented the recommendations, and you can see our NSGs below.

                                      This screenshot shows an example of the NSG associated with our bastion host:

                                      screenshot of network security groups associated with Netskope bastion

                                      The default NSG rules will allow the bastion to connect to the virtual machines, but it allows all ports and protocols. This screenshot shows an example of the NSG associated with our virtual machines:

                                      screenshot example of the NSG associated with Netskope virtual machines

                                      The NSGs contain inbound and outbound rules. These are processed in the order of the priority number assigned, with the lowest number taking precedence. As traffic is evaluated, if it does not match the lower numbers, it will progress and eventually be caught by the “Deny” statements at the highest values. In this example, any traffic that originates from within the Virtual Network will be allowed to hit the network interface of the virtual machine(s).

                                      If you applied a rule with a higher priority that blocked the traffic from the Bastion, you will no longer be able to connect. The message from the Azure portal may be something like this:

                                      screenshot example of azure portal message

                                      If you see the message in the screenshot above when attempting to connect to a virtual machine, we recommend checking to make sure that the SSH traffic is not blocked.

                                      Virtual Machine Configuration

                                      The virtual machine must be a member of the network security group (NSG) that allows traffic within the virtual network. It will allow the bastion instance to start an SSH session on the virtual machine on your behalf.

                                      Identity Management

                                      Access to the virtual machine

                                      The Azure user must have the following permissions assigned in order to use the bastion instance to connect to virtual machines:

                                      • Reader role on the virtual machine
                                      • Reader role on the NIC with private IP of the virtual machine
                                      • Reader role on the Azure Bastion resource

                                      Managing the SSH keys

                                      If you are using SSH keys, then you must have the public key on the virtual machine(s), and then you will use the private key to create a successful session. The screenshot below shows the connection screen for a virtual machine:

                                      screenshot of connection screen for virtual machine

                                      The bastion host does not save the private key or password. This is always supplied by the end user who is attempting to make a connection, so the user must know which key to use and have access to it outside of this workflow. In the example above, I know that the local username on the virtual machine is “azureuser’” and I’m about to paste my private SSH key in the box to establish a connection. This will succeed because the corresponding public key is already on the virtual machine.

                                      Logging and Monitoring

                                      Monitoring live connections

                                      Azure allows administrators of the bastion hosts to monitor and even disconnect active sessions. Below is a screenshot of what it looks like in the Azure portal when you have an active connection:

                                      screenshot of Azure portal when you have an active connection

                                      Saving audit logs from a bastion

                                      In addition to monitoring live connections, we will likely want to keep a historical record of sessions. Information about how to set up logging is available here. Azure allows you to send bastion audit logs to one of the following destinations:

                                      • Log Analytics
                                      • Storage Account
                                      • Event Hub

                                      The audit logs from the bastion host include connect and disconnect events, which include the following metadata:

                                      • Timestamp
                                      • Destination IP address
                                      • Destination port
                                      • IP address of the originating request
                                      • Port of the originating request
                                      • SSH username

                                      There is no way to obtain full session logs from the bastion service.

                                      Conclusion

                                      In this post, we showed how the Azure Bastion service can be used to remotely access your virtual machines, and the solution we implemented with this service met all of the following requirements:

                                      • Public IP addresses are not required to be associated with the virtual machines in order to enable remote access.
                                      • We eliminated the possibility of SSH multiplexing attacks.
                                      • Remote access session information is captured in audit logs.

                                      Although the initial connection happens with Azure credentials, you must still maintain SSH keys for access to the virtual machines. Azure Bastion may not be for you if your users must use SSH clients from their machines directly, as it only supports access through the Azure Portal. According to the Azure documentation, there is no way to use the bastion service via CLI.

                                      If you are interested in looking at similar solutions in other cloud providers, be sure to check-out the previous blog posts in this series:

                                      Leaving Bastion Hosts Behind Part 1: GCP

                                      Leaving Bastion Hosts Behind Part 2: AWS

                                      The next post in our blog series will examine a cross-cloud solution using Netskope Private Access.

                                      author image
                                      Colin Estep
                                      Colin Estep has 16 years of experience in software, with 11 years focused on information security. He's a researcher at Netskope, where he focuses on security for AWS and GCP.
                                      Colin Estep has 16 years of experience in software, with 11 years focused on information security. He's a researcher at Netskope, where he focuses on security for AWS and GCP.

                                      Stay informed!

                                      Subscribe for the latest from the Netskope Blog