Securing Bitbucket in AWS
デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりました。テンプレートは今後も利用できますが、保守や更新は行われません。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。
AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。
This page describes security best practices for running and maintaining Bitbucket in AWS.
Amazon Virtual Private Cloud (VPC) and Subnets
Amazon VPC enables you to launch AWS resources into a virtual network that you've defined. This virtual network closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of AWS. See Amazon EC2 and Amazon Virtual Private Cloud for more information.
A subnet is a range of IP addresses in your VPC. You can launch AWS resources into a subnet that you select. Use a public subnet for resources that must be connected to the internet, and a private subnet for resources that won't be connected to the internet.
See Amazon's article called Your VPC and Subnets for a general overview of VPCs and subnets.
To bolster the security of your VPC you may wish to enable one or more of the following:
- Secure your VPC with a firewall virtual appliance / AMI to defend against unauthorized network activity
- サイト間 VPN を設定して、Bitbucket とそのユーザー間で情報が安全に転送されるようにする
- Configure an intrusion prevention or intrusion detection virtual appliance to detect when unauthorized network activity has occurred
- Enable Amazon CloudTrail to log VPC API operations and keep an audit trail of network changes
Atlassian Standard Infrastructure
AWS クイック スタートで Bitbucket をデプロイした場合、Atlassian Standard Infrastructure (ASI) が使用されます。ASI は、すべての Atlassian Data Center アプリで必要なコンポーネントを含む仮想プライベート クラウド (VPC) です。詳細は「AWS の Atlassian Standard Infrastructure (ASI)」をご参照ください。
Security Groups
A security group acts as a virtual firewall that controls the traffic for one or more instances. The security group(s) that apply to newly launched instances depend on your launch method:
- If you launched instance(s) via the AWS console or API, the EC2 launch process gives you the opportunity to either create a new security group or associate one or more existing security group(s) with the instance. We recommend allowing inbound access to Bitbucket only on ports 22, 80, 443, and 7999, and only allowing access from the tightest possible IP address range.
- If launched via BitbucketServer.template or BitbucketDataCenter.template, AWS CloudFormation creates and manages a security group as part of the stack, allowing inbound access on ports 22, 80, 443, and 7999 from the Permitted IP range of addresses you specify. We recommend specifying the tightest possible Permitted IP range and not adding unnecessary inbound access to the security group after launch.
We recommend using security groups to restrict incoming traffic to your Bitbucket instance to the absolute minimum required.
See Amazon EC2 Security Groups for Linux Instances for more information.
HTTPS を有効化するように SSL を構成する
HTTPS を有効にするには、有効な SSL 証明書が必要です。SSL 証明書は、商業ベースのサービスを提供する VeriSign、DigiCert または Thawte などの信頼できるサードパーティ認証局 (CA) によって発行されている必要があります。アトラシアンではこのようなサービスは提供していません。
CA から適切な SSL 証明書を取得したら、AWS 証明書マネージャにインポートできます。これにより、後で AWS に Bitbucket をデプロイするときに証明書を使用できます。これを行うには (たとえば、クイック スタートで Bitbucket をデプロイする場合)、証明書の Amazon リソース番号 (ARN) を提供する必要があります。
有効な SSL 証明書をインストールするまで、新しい Bitbucket Server と Data Center インスタンスは、HTTPS ではなくプレーンな HTTP 経由でリクエストを処理するように構成されます。つまり、すべてのパスワードとデータは、パブリック インターネット経由で暗号化されずに送信されます (ユーザーが仮想プライベート ゲートウェイ経由で AWS に接続されている場合を除く)。
SSL を有効または無効にした場合のロード バランサ設定
SSL を有効にして Bitbucket をデプロイすると、ロード バランサのリスナーは次のようにセットアップされます。
| Load Balancer Protocol | Load Balancer Port | Instance Protocol | Instance Port |
|---|---|---|---|
| http | 80 | http | 7991 |
| HTTPS | 443 | http | 7990 |
初回起動時に SSL 証明書をセットアップしていない場合、ELB は次のように 1 つの HTTP リスナーでのみ設定されます。
| Load Balancer Protocol | Load Balancer Port | Instance Protocol | Instance Port |
|---|---|---|---|
| http | 80 | http | 7990 |
すべての自己署名 SSL 証明書を置き換える (Bitbucket Server の場合)
クイック スタートを使用して Bitbucket Data Center をデプロイする場合は、起動時にすぐに適切な CA 証明書をデプロイに提供できます。ただし、BitbucketServer.template を介して Bitbucket Server をデプロイする場合（または「AWS で Bitbucket を手動で起動する」に従い手動でデプロイする場合）は、現在、初回起動時に独自の SSL 証明書をインストールする方法がありません。
Bitbucket Server インスタンスをインターネットに接続する場合、ATL_SSL_SELF_CERT_ENABLED=true を設定し、ご利用のインスタンスで起動時に HTTPS を有効化することをおすすめします。この設定を行うことで、Bitbucket Server インスタンス用の自己署名証明書が生成されます。
自己署名証明書は、適切な CA が発行した証明書と同じレベルのセキュリティを提供しません。Bitbucket Server インスタンスが自己署名証明書を使用している場合は、次のようになります。
- most browsers will display security warnings that must be ignored before proceeding to the Bitbucket Server Web interface
- git クライアントは、
git config --global http.sslVerify falseで自己署名証明書を無視するように構成されている場合を除き、Bitbucket Server への HTTPS 経由での接続を拒否します。 - application links and/or integrations with other applications that use Bitbucket Server's REST API and don't accept self-signed certificates may fail
このため、すべての自己署名 SSL 証明書をドメイン用の適切な CA 証明書に置き換えることをおすすめします。これを行うには、次の操作を実行します。
- 証明書ファイルを
/etc/nginx/ssl/my-ssl.crtなどにに配置します。 - password-less 証明書キー ファイルを
/etc/nginx/ssl/my-ssl.keyに配置します。 /etc/nginx/nginx.confを次のように編集します。/etc/nginx/ssl/self-ssl.crtへの参照を/etc/nginx/ssl/my-ssl.crtに置き換えます。/etc/nginx/ssl/self-ssl.keyへの参照を/etc/nginx/ssl/my-ssl.keyに置き換えます
/etc/nginx/ssl/my-ssl.crtのコンテンツを既定のシステム PKI バンドル (/etc/pki/tls/certs/ca-bundle.crt) に適用し、インスタンスのスクリプト (DIY バックアップなど) が正常にcurlを実行されるようにします。- Restart nginx.
デプロイ後に SSL 証明書をインストールまたは変更する
クイック スタートを使用して Bitbucket Data Center を初めてデプロイする場合は、適切な CA 証明書を提供することをおすすめします。これを行うには、証明書を AWS Certificate Manager にインポートし、[SSL 証明書の ARN] フィールドから Amazon リソース番号を指定する必要があります。
クイック スタートを使用したデプロイ中にこれを行わなかった場合 (または自己署名証明書を使用した場合)、初回デプロイ後にいつでも SSL 証明書をインストールまたは変更できます。
- AWS コンソールで、[サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新]をクリックします。
- [SSL 証明書の ARN] フィールドで証明書の Amazon リソース番号 (ARN) を指定します。詳細については、「AWS Certification Manager への証明書のインポート」を参照してください。
<Bitbucket home directory>/sharedディレクトリにあるbitbucket.propertiesファイルで、HTTP から HTTPS へのリダイレクトを手動で設定します (「HTTP リクエストを HTTPS にリダイレクト」を参照)。Restart the Bitbucket service by running the following command on all application nodes
sudo service atlbitbucket restart
Bitbucket インスタンスのホスト名が変更された場合は、「Bitbucket のベース URL を指定する」ページの説明に従い、Bitbucket のベース URL を更新する必要があります。
Keeping your system up-to-date
It is essential to keep your Bitbucket Server instance up-to-date with patches and updates to maximize security and minimize opportunity for exploits and misadventure. On first boot a Bitbucket Server AMI instance will download the latest official release of Bitbucket Server at that time so you are assured of having the very latest version of Bitbucket Server when you first start using Bitbucket Server in AWS.
Amazon Linux Security Updates
The Bitbucket Server AMI is based on Amazon Linux and the latest version of this is used whenever we cut a new release of the Bitbucket Server AMI. Occasionally vulnerabilities in libraries and utilities used in Amazon Linux will be detected and updates posted in the Amazon Linux AMI yum repository. Atlassian will issue new versions of the Bitbucket Server AMI where necessary to ensure new Bitbucket Server AWS instances start with these updates but if you are managing an existing instance you may need to apply these updates yourself. By default, Amazon Linux applies all security updates on reboot. Alternatively you can run "yum update --security".
You may wish to apply other updates from the Amazon Linux AMI yum repository to your Bitbucket Server instance. You must ensure that any updated packages are supported by the version of Bitbucket Server you are running. Bitbucket Server version requirements can always be found on the Supported platforms page.
Bitbucket Server Updates
アトラシアンの Bitbucket Server チームは一定のリリース頻度の確保に取り組んでおり、新機能、パフォーマンス、およびセキュリティの修正を含むリリースを定期的に発行しています。Bitbucket Server をできる限り最新に保つことを強くおすすめします。既存のインスタンスで Bitbucket Server を更新するには、「Bitbucket Server アップグレード ガイド」に従います。