VOYAGE GROUP　エンジニアブログ

こんにちは。システム本部の@yuu_itoです。
主に弊社のメディアサービスのデータ分析の業務を行っています。

昨今、世間ではセキュリティに関する問題が増加しています！

情報セキュリティにおいて最小権限の原則という用語もあったりしますが、
システムの利用者に本当に必要な権限のみを付与することで
誤った操作を予防したり、外部からの侵入が起きてしまった場合にも
損害を最小限にできるように設計することが大事です。

前回の記事ではBigQueryについて書かれていましたが、
同様のDWH(データウェアハウス)機能を提供するサービスとしてAmazon Redshiftがあります。
今回はRedshiftのデータベースアクセスコントロールの設定方法について調べてみました。

■ データベース
データベースに対する権限設定コマンドは
PostgreSQLや、MySQL同様GRANT、REVOKEコマンドが使えます。 ALLは全権限、CREATEはスキーマ作成、TEMPORARYは一時表を作成する権限です。
テーブルへの SELECT や UPDATE の権限についてはスキーマ単位、テーブル単位で設定する必要があります。

■ スキーマ
MySQLではスキーマとデータベースは同義である(*1)と思いますが、Redshift、PostgreSQLではデータベースの中にスキーマがあり、スキーマの中にテーブルを配置するイメージです。 Redshiftのオブジェクト構成イメージ

スキーマの操作もGRANTコマンドを使います。 PUBLICスキーマについて
Redshiftは各データベースにデフォルトでPUBLICいう名のスキーマが存在し、全てのユーザ（全ユーザはPUBLICグループに所属している）にCREATE権限がついています。書込み権限が不要なユーザも存在すると思うので、REVOKEでCREATE権限を除いておくと良さそうです。
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_Schemas_and_tables.html

■ テーブル、カラム
テーブルについてもGRANTで個別に設定できます。しかしDBやスキーマのレベルでのみ管理するルールにしておけば、テーブル単位での管理をする必要はなくなるのでDB管理者としては気にすることが減って良さそうです。

カラム単位での操作制限はサポートされていなかったです。
一部のカラム隠蔽したいのであれば、ビュー(View)を作成したり、COPYコマンドでカラムを絞ってロードすることもできます。
また、CREATE TABLE AS(通称CTAS:しーたす)だったりINSERT INTO SELECTを使ってテーブルコピーを作る方法があります。

ビューの場合、テーブルコピーよりもコストが低い反面データベースをまたいだ作成ができないためテーブル、ビュー単位での管理が必要になります。 逆にCTASであればデータベースをまたいで作成することができるので、DBやスキーマのみの管理で済みます。

例えば、個人情報を除いたテーブルを権限を分けた別のデータベースやスキーマに作成すると良さそうです。 スキーマ、テーブルの構成例 CTASのコマンド例

■ ユーザの権限確認方法
データベース、スキーマ、テーブル単位で権限をチェックする関数がありました。
コマンド一発！一覧で確認するようなコマンドがあると期待していたのですが見つからず...
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_System_information_functions.html
HAS_XX_PRIVILEGEを使って確認できました。
試しに書いてみたクエリをgistに貼っておきます。
https://gist.github.com/yuu-ito/30733a9223e59e32bdb5#file-acl_check-md

■ まとめ
簡単でしたが、Redshiftの操作権限の設定とその方法について調べてみました。今回はDBユーザのセキュリティのみに焦点をあてましたが、実際にはネットワーク構成やデータの元となる運用サービスのデータベースサーバなどの関連システムについても一緒に整理する必要があります。AWSサービスでのシステム構成設計についてはいろんな記事でまとめられているのでそちらを探してみてください。

■ 参考
データベースセキュリティの管理 - Amazon Redshift
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_Database_objects.html
*1:
http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_schema

■ お約束
VOYAGE GROUPでは、一緒に働いてくださる仲間を募集しております。
株式会社VOYAGE GROUP アドテクユニット キャリア採用サイト
株式会社VOYAGE GROUP - 採用
どんな会社か気になる方は、是非下記のサイトもご覧ください。
VOYAGE CULTURE

こんにちは、adingo で Fluct という広告配信まわりのインフラやってる あわいいしま (@katz_arc) です。
月間200億超のインプレッションを捌くSSP である Fluct を支えるべく、日夜頑張っております。

今回はタイトルの通り、Amazon VPC で使える仮想プライベートゲートウェイを使わずにオンプレのデータセンター (以下 IDC) と VPC の間を VPN 接続したお話です。

前提

過去には仮想プライベートゲートウェイを利用して VPN 接続を構築したこともあります。
それが何故、その VPN 接続を使わずに自前で構築しようと考えたか、そこには2つほど理由がありました。

1. ゲートウェイを作成するたびに Global IP アドレスが変更されてしまうのが困る

VPN  接続を行うために重要なパラメータとなる IP アドレスが変更されると、それに伴い IDC 側 L3 スイッチの ACL を修正する必要があります。
これは何度もやりたい (やるべき) 作業ではありません。

2. 自分で1から設定する事により AWS  のネットワーク的挙動を確認したかった

VPN 接続を行おうとすると、通常の EC2 インスタンスを利用するだけであれば知らなくても困らない設定を行う必要がでてきます。
それにより AWS 独特な挙動、特にネットワークまわりをより知ることができるかもしれないという期待がありました。

材料

今回 VPN 接続に利用するのは VyOS です。
VyOS は Vyatta という OSS なソフトウェアルータが Brocade に買収され、無償版である Vyatta Core の新規開発が終わってしまった際に無償版からフォークして生まれました。
詳細は wikipedia の Vyatta と VyOS の頁を見てください。

IDC 側は専用のサーバは準備せず、KVM を利用して VyOS を立ち上げました。
自分の環境では bridge インタフェースを作るにあたり、bonding インターフェース直から VLAN インタフェースへの切り替えなど、いくつかホスト側の設定変更が必要になりました。

AWS 側は Community AMIs に VyOS 1.0.4 があるのでそれを利用しています。(作業時は ami-ad590eac on apne)
Community AMI ですし、利用にあたってはご自身の責任の元でお願いします。

レシピ図

VPN 接続の構成を簡単に図で、今回は vti (仮想トンネルインタフェース) は利用していません。


手順

1. IDC 側 VyOS の準備

KVM を使っての OS インストールは本題ではないので割愛します。
設定に必要な情報はレシピの図を参考にしてください。

1つ補足すると、VyOS は debian ベースであるものの、ソフトウェアルータですのでネットワークの設定などすべて専用コマンドで設定していきます。例として、console に繋いで IP アドレス、default gateway、ssh のサービスを設定するのであれば以下のようにします。

configure
set interfaces ethernet eth0 address 172.16.100.1/24
set interfaces ethernet eth1 address 192.168.100.1/24
set system gateway-address 192.168.100.254
set service ssh listen-address 172.16.100.1
commit
save

ここから VPN の設定を入れ込んでいきます

set vpn ipsec ipsec-interfaces interface eth1
set vpn ipsec ike-group to_AWS lifetime 28800
set vpn ipsec ike-group to_AWS proposal 1 encryption aes128
set vpn ipsec ike-group to_AWS proposal 1 hash sha1
set vpn ipsec esp-group to_AWS lifetime 3600
set vpn ipsec esp-group to_AWS proposal 1 encryption aes128
set vpn ipsec esp-group to_AWS proposal 1 hash sha1
set vpn ipsec site-to-site peer 192.168.200.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.168.200.1 authentication pre-shared-secret vpnsecret
set vpn ipsec site-to-site peer 192.168.200.1 authentication id @idc01
set vpn ipsec site-to-site peer 192.168.200.1 authentication remote-id @aws01
set vpn ipsec site-to-site peer 192.168.200.1 default-esp-group to_AWS
set vpn ipsec site-to-site peer 192.168.200.1 ike-group to_AWS
set vpn ipsec site-to-site peer 192.168.200.1 local-address 192.168.100.1
set vpn ipsec site-to-site peer 192.168.200.1 tunnel 1 local prefix 172.16.100.0/24
set vpn ipsec site-to-site peer 192.168.200.1 tunnel 1 remote prefix 10.0.200.0/24
commit
save

これで IDC 側の設定は完了です

2. AWS 側 VyOS の準備

インスタンス作成にあたり幾つか注意点を

• VPN を利用するために SecurityGroup の設定で IDC 側 VyOS からの IKE(UDP:500)/ESP(IP:50) を開放する必要があります。
• VyOS はともかく、その先の本来接続したいサーバ (今回であれば AWS Manager) にとっては IDC 宛はプライベート IP アドレス同士での接続となるため、ルーティングテーブルをなんらかの方法で設定する必要があります。これは subnet に付与する rtb で対応します。

インスタンス起動については割愛します。IKE/ESP 以外の SG は環境に合わせて設定してください。
IDC 側プライベートアドレスへのルーティング設定は Management Console で設定できなかったため、以下の様にして設定しました。(awscli 利用)

aws ec2 create-route --route-table-id rtb-(public subnet の rtb-id) --destination-cidr-block 172.16.100.0/24 --network-interface-id eni-(VyOS インスタンスの eth0 に attach された eni-id)

上記以外は特に難しいところはありません。

configure
set interface eth0 address dhcp

set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec ike-group to_IDC lifetime  28800
set vpn ipsec ike-group to_IDC proposal 1 encryption aes128
set vpn ipsec ike-group to_IDC proposal 1 hash sha1
set vpn ipsec esp-group to_IDC lifetime  3600
set vpn ipsec esp-group to_IDC proposal 1 encryption aes128
set vpn ipsec esp-group to_IDC proposal 1 hash sha1
set vpn ipsec site-to-site peer 192.168.100.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.168.100.1 authentication pre-shared-secret vpnsecret
set vpn ipsec site-to-site peer 192.168.100.1 authentication id @aws01
set vpn ipsec site-to-site peer 192.168.100.1 authentication remote-id @idc01
set vpn ipsec site-to-site peer 192.168.100.1 default-esp-group to_IDC
set vpn ipsec site-to-site peer 192.168.100.1 ike-group to_IDC
set vpn ipsec site-to-site peer 192.168.100.1 local-address 10.0.200.1
set vpn ipsec site-to-site peer 192.168.100.1 tunnel 1 local prefix 10.0.200.0/24
set vpn ipsec site-to-site peer 192.168.100.1 tunnel 1 remote prefix  172.16.100.0/24
commit
save

これで AWS 側の設定は完了です

3. 接続確認

両方の設定が完了したので接続の確認をしてみます。

まず IPSec の接続性を確認してみます

on IDC

vyos@vyos:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP
------------                            -------------
192.168.200.1                            192.168.100.1

    Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----  -----  ------  ------  -----
    1       up     0.0/0.0        aes128   sha1  no     3098    3600    all

on AWS

vyos@vyos:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP
------------                            -------------
192.168.100.1                         10.0.200.1

    Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----  -----  ------  ------  -----
    1       up     1.3K/1.3K      aes128   sha1  no     449     3600    all

IDC からみた時の Peer ID/IP と AWS 側の Local ID/IP に差がある (EIP or Private IP) ことがわかります

VyOS 同士での ICMP 疎通を確認します (ping のオプション設定が通常の Linux 違います)

on IDC

vyos@vyos:~$ ping 10.0.200.1 count 5
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
64 bytes from 10.0.200.1: icmp_req=1 ttl=64 time=7.61 ms
64 bytes from 10.0.200.1: icmp_req=2 ttl=64 time=7.74 ms
64 bytes from 10.0.200.1: icmp_req=3 ttl=64 time=7.71 ms
64 bytes from 10.0.200.1: icmp_req=4 ttl=64 time=7.75 ms
64 bytes from 10.0.200.1: icmp_req=5 ttl=64 time=7.83 ms

--- 10.0.200.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 7.611/7.731/7.834/0.071 ms

on AWS

vyos@vyos:~$ ping 172.16.100.1 count 5
PING 172.16.100.1 (172.16.10.40) 56(84) bytes of data.
64 bytes from 172.16.100.1: icmp_req=1 ttl=64 time=7.74 ms
64 bytes from 172.16.100.1: icmp_req=2 ttl=64 time=7.90 ms
64 bytes from 172.16.100.1: icmp_req=3 ttl=64 time=7.57 ms
64 bytes from 172.16.100.1: icmp_req=4 ttl=64 time=7.63 ms
64 bytes from 172.16.100.1: icmp_req=5 ttl=64 time=7.87 ms

--- 172.16.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 7.574/7.748/7.905/0.130 ms

ネットワーク的な疎通は問題なさそうです。
それでは本来の目的である VyOS の先にあるサーバ (インスタンス) 同士の接続を確認します
(IDC Manager には事前に 10.0.200.0/24 へのルートを 172.16.100.1 で設定してあります)

[root@IDC_Manager ~]# traceroute 10.0.200.2
traceroute to 10.0.200.2 (10.0.200.2), 30 hops max, 60 byte packets
 1  172.16.100.1 (172.16.100.1)  0.380 ms  0.492 ms  0.583 ms
 2  10.0.200.1 (10.0.200.1)  8.565 ms  8.817 ms  8.904 ms
 3  10.0.200.2 (10.0.200.2)  9.095 ms !X  9.274 ms !X  9.395 ms !X

traceroute に global ip address (今回であれば 192.168.100.x or 192.168.200.x) が出てこないことがわかります

最後に ssh です (SG の設定で 172.16.100.0/24 からの ssh を許可してあります)

[root@IDC_Manager ~]# slogin -i (aws の鍵) 10.0.200.2
[root@AWS_Manager ~]#

できました

まとめ

出来上がってしまえば一般的な LAN 間 VPN と同様な感覚で利用可能な環境ができました。

実際の利用環境では VyOS を設置した public subnet の裏に private subnet があり、その接続のために VyOS インスタンスへの ENI 追加、private subnet で利用する rtb に IDC 宛の接続設定なども行っており、環境によっては少し手間がかかることもあるかもしれません。

とは言え、VyOS を稼働させるのに必要なインスタンスもそれほどスペックは必要ありませんし、一度試してみては如何でしょうか。自分は次に VyOS のような専用 OS ではなく、汎用 Linux 上の OpenVPN での接続も試してみようと企んでいます。

お知らせ

最後にお約束となりますが、弊社には ajito という社内バーがあり、エンジニアが夜な夜な出現してビールを飲んだり技術的な話をしたりと楽しい場になっています(#ajiting といいます)。弊社エンジニアに一声掛けてくださると、無料でビールを飲みつつ歓談できるかと思います。また、勉強会の場としても提供していたりするので、アドテクに興味ある方もそれほど興味ない方もどんどんお声掛けください