S3をリバースプロキシする際の疑問点調査

nginx(EC2)でリバースプロキシしてS3を公開した際に
・Static website hosting は必要かどうか?
・S3エンドポイント を利用すると設定で変更するところはあるのか?
がわからなかったため調査。

結論として
・Static website hostingは必要なし。
・S3エンドポイントをバケットポリシーで制御する必要がある。
ことがわかった。

S3設定

バケット名:bucket–name
を作成して、[1.png]をアップロードした。

URLは以下となる。
http://bucket–name.s3.amazonaws.com/1.png
http://bucket–name.s3-ap-northeast-1.amazonaws.com/1.png
http://s3-ap-northeast-1.amazonaws.com/bucket–name/1.png

また外部から閲覧するためにアクセス権限を設定した。
(以下はIPアドレスx.x.x.xに公開する場合)

{
  "Id": "Policy1505038915778",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1505038910815",
      "Action": [
        "s3:GetObject"
      ],
      "Principal": "*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::bucket--name/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "x.x.x.x"
        }
      }
    }
  ]
}

nginxのリバースプロキシ設定

location / {
        set $s3_bucket        'bucket--name.s3.amazonaws.com';
        proxy_set_header       Host $s3_bucket;
        proxy_hide_header      x-amz-id-2;
        proxy_hide_header      x-amz-request-id;
        proxy_hide_header      Set-Cookie;
        resolver               10.0.0.2 valid=300s;
        resolver_timeout       10s;
        proxy_pass             http://$s3_bucket;
}

Static website hosting について

・有効にすると、公開用のURLが追加で作成される。(無効にすると利用できなくなる。)
http://bucket–name.s3-website-ap-northeast-1.amazonaws.com
・上記URLに限り、インデックスドキュメントとエラードキュメントやリダイレクトが動作する。
・DNSを設定することで、独自ドメイン(バケット名)も利用できる。

つまりこの機能を利用しなくても、リバースプロキシのオリジンに設定することが可能。

S3エンドポイント時の設定

バケットポリシーに以下を追加する必要がある。

{
    "Version": "2012-10-17",
    "Id": "Policy1505038915778",
    "Statement": [
        {
            "Sid": "Stmt1505038910815",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucket--name/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "x.x.x.x"
                    ]
                }
            }
        },
        {
            "Sid": "Stmt1505038910816",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucket--name/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceVpce": "vpce-xxxxxxx"
                }
            }
        }
    ]
}

参考

[Nginx] Nginx で S3 をリバースプロキシする
http://blog.serverworks.co.jp/tech/2016/08/22/vpc_endpoint_s3_backet-2/

第2回すだちくん勉強会に参加した

第2回すだちくん勉強会に参加した。その時のメモ。

サーバーワークスが実践するカルチャーインストール3つのポイント 大石良氏

サーバーワークス歴史

2008年 社内サーバー購入禁止令
2009年 新規案件はAWSのみ
2011年 日本赤十字社がダウン(AWS構成で提案し、30分で構築完了)。その後義援金管理システム導入。
そこからAWSの導入が加速した。

サーバワークスの「文化」

創業者だけが当事者として伝えられること

2つの環境要因
・生産人口の低下
・Uberization:ITが文化を壊す
→エンジニアの価値・若手の価値が相対的に増大
クラウドで世界をもっと働きやすくするためにしていることについて

BYOD制度

利用者には手当を支給
その結果、自然とクラウドワークスタイルが生まれた(事前申請性の時間や場所にとらわれない働き方)

場所にとらわれない働き方

リモートワーカーの気持ちがわかるためにリモート飲み会など実施
やってみてわかったメリットとして、帰りやすく、精算がフェア

ファシリティ

なぜ会社にいるのか?→たいていはそこにパソコンがあるからではないか?
既存の社員がはたらきやすくなるオフィスにすることが大切
社員内で委員会を立ち上げてもらって検討してもらうことに

メールを禁止

Slackを利用
 文字コミュニケーションの場合「怒ると叱るとは違う」は通用しない(マイナスにしかならない)
 ガイドラインを定期的にbotにつぶやかせるなどルールを定めて守れるようにしている
 有効活用している(工数管理bot:作業前に何をするかつぶやくと、作業時間を日時で集約してくれる)

クラウドで重視すること

オンプレミス時代はハード事前購入が必須であり、失敗が許されない
ユーザも大きめのハードを買う。ハードが大きくなれば関係者も大きくなる
→保険能力、人員数の調達能力が重要だった
クラウドでは適切に組み合わせられるかがすべて

オンプレミス時代と変わらないものはセキュリティであるが
売上をあげるためのセキュリティを意識している

人事制度

自由度が高いため、骨太な人事制度が必要
「成果をみる」ことを重要視する

まとめ

ワークスタイル変革は目的ではない
 優秀な人に入社してもらい、長くいてもらうために
 すべての会社で必要になる絶対不可欠な取り組み
ワークスタイル変革に必要なことはソフト・ハードとそれを用いる文化の組み合わせ
 文化と信頼を築くための文化が必要
行動から文化を作ることができる

これからはじめるセキュリティ 河野省二氏

bit.ly/2psZKOk

健康のためにサプリだけ飲んでいますという考え方が一番危険
仕組みを理解して防御しなくてはならない

攻撃を因数分解して守るべし

標的型メール攻撃を題材に検討する
 メール、リンク・添付ファイル→ウイルス感染→権限昇格→情報入手
 リスクをこのように因数分解して、どこで対応を考えるか
  時間がかかるようなところで対応するべし
   権限昇格に時間がかかるため、もしウイルス感染したとしても権限昇格を抑えれば問題ない
   ランサムウェアは「情報入手」が「ファイル暗号化」に変更されるだけであるため
   標的型攻撃対策をしていれば、本質的にはランサムウェアを恐れることはない
    (またここまで標的型攻撃が言われるようになったのは経済産業省があまりにも周りが対応しないため、
     標的型攻撃対策を謳うようになったためらしい)
 メディアに頼るとUSBを禁止したり、出口対策をしたりするような効果が薄い対応をしてしまう
  そのためまずはリスクのチェーンを作成する
   スパムメールをなくすためには→gmailやOffice365を利用したほうがよい
  添付メールを減らす
  1通添付して5人にメールすると、メールサーバやローカルなど合わせて20以上のファイルがコピーされる
 そして管理できない情報が増えることになる

IT制限をして効率悪化させないために

例えば年金機構はメールを利用しない
→IT制限による効率悪化が発生する
 →どのようにしたらメールが利用できるかを検討することが必要
  原因不明のときは何かが利用禁止になる。阻止するためにはログが必要

木を見て森を見る

報道義務があるのは個人情報だけ
 個人情報を抜かれた場合は、実はすべてを抜かれている状態
 サイバーセキュリティ事故は犯人が捕まらないと動機がわからない(しかし殆どの場合は捕まらない)

世の中の流れをSecurity目線でも考える事

今流行しているマイクロシステムのほうが守りやすい
メールライブラリに問題があれば、柔軟に切り替えられるように
できなければ別途守る仕組みが必要で、費用がかかり、柔軟性が低くなる

セルフサービス化

運用がセルフサービスできるようにしているのがクラウド
人間が関与を最小限にすることが情報セキュリティの目標の1つ
情報漏えいからなりすましが流行してきているため別のアプローチも必要

大谷晋平氏

※タイトルは見逃し

AWSにジョインした理由

AWSの中身を知るためには、入らないとわからない
(broadcast.amazon.com という動画で様々な仕組みの動画が見放題
S3の仕組みが2時間*10本ほど)
AWSは利用者と運用者でそれぞれ極める必要がある
今後営業だけしかできない人員はいらなくなるかも

やめるに至った理由

提供だけではなく、構築してみたいとモヤモヤしてきた
事業成功の喜びを見たかった

神戸康多氏

vuls誕生について

社会人13年目(12年間発表などしたことがなかった)
・100台弱のカオス環境
 オープンソースのアップデートは他人のバグの穴埋め作業
 クリエイティブな思想が生まれにくくなる
 →どうにかしたいという怒りがvulsを産んだ

新機能など

・各OSが出している脆弱性情報をOVALスキャンするバージョンを準備予定
 changelogでなくなることで検知精度の向上
 NVD,JVNに掲載されていない脆弱性情報が表示可能に
・VulsのSaaS版を作ることになった

CASBについて シンジ氏

利己的なコミュニティ(JAWS)への怒りを感じたことがすだちくん勉強会の始まり

CASB
・ビジネスを進める?セキュリティ進める?
・シャドーITは絶対ダメ
・やるべきはデータ保護

VPNや閉域網で複数拠点を接続する、つまりネットワークで問題解決を図ろうとしてきた
ビジネスの付加価値としてセキュリティがある
組織のシャドーITはどうころんでも悪
ブロックではなくて安全に使わせる
ネットワークではなくて、データを制御する
統制は不可能
120人で180種類のクラウドサービスを利用している
ガートナーによるとシャドーITのたった5%しか守れていない

そのために必要な5つのSaaS

・G Suite
・Office 365
・box
データ保管
データは貯めるものではなく、使うもの
極端に言えばファイルサーバ
これらは別機構でも代用可能

以下がポイントとなる
・netskope
データ統制
セキュリティの高さを測ることが可能
データの可視化と制御が可能
シャドーITを撲滅させる現在唯一の手段
使っているサービスを購入したりして、どんどん推し進めることが可能
・druva
データ保護
バックアップサービス
すべての端末(パソコンやスマホ)も可能

金額の目安
box(500-1200円/月・事例だすと鬼値引きがあったり・ユーザアカウントしない課金方法も)
netskope(12000円/月・国内代理店から購入、そろそろ日本オフィスできる)
druva(15000円/月)
 エンタープライズ向けのサービス
 ライセンスは「基本的に」ユーザあたり年間課金

Iret社は今日紹介した製品すべての販売代理店

osc2017-tokyo/spring に参加した

osc2017-tokyo/springに参加した。その際のメモ。

PowerDNSとその周辺OSSのご紹介〜BINDはもういらない〜 大野 公善氏

株式会社デージーネットについて

事業理念「よりよい技術で、インターネット社会の安心と便利に貢献します」
名古屋と東京に拠点がある。

PowerDNSについて

1999年にプロジェクト発足(ある企業のクローズドソース)
2005年にOSSになった
Authoritative Server 4.x からはソフトウェアが成熟してきている
(3.X系は機能追加が盛んに行われていた)

・権威DNSとキャッシュDNSサーバで構成されている。(それぞれが別プロセスで動作する)
・バックエンドのDBとして、MySQLやLDAPなどさまざまなDBが可能
・Poweradminという管理ウェブインターフェースと組み合わせて利用可能
 管理コンソールを利用して、統計から異常な問い合わせがないか調べることが可能
 DNSゾーンやレコードの管理が可能
 ユーザごとにアクセス権限を付与することが可能
 日本語対応している
・BINDより早い
 ベンチマークにqueryperf(bind付属ツール)を使用したところquery/secが1.2倍くらい
・DNSSECサポート
 pdnsutilというコマンドを利用
・REST APIが利用可能
 統計情報を取得可能
・BINDからのゾーンファイルの移行
 zone2sqlというコマンドが用意されている
・ 脆弱性は1年間に18個でBindと比較して少ない
・KnotDNS、NSDなどをフロントにおいても良いかも
・サーバの統計情報をグラフ化するcollectdというOSSがある
 DnsAnswer・DnsQuestion・Latencyなどをグラフ化可能

冗長化について

・DRBD + Pacemaker + Corosync で完全冗長化可能
・MariaDB Galera Clusterや負荷分散装置をおくことで冗長化
→Hawk(HAクラスタコンソール)を利用すると便利
 openSUSEが作成している

その他

メールサーバのセキュリティ診断サイトを立ち上げました。
メールサーバセキュリティ診断 | MSchecker
メールサーバの情報は第三者に公開されることはありません、とのこと。

質問したこと

・PowerDNSの冗長化構成にVIPを利用していたが、ネームサーバのプライマリ・セカンダリ利用では問題になるのか。
→どちらでも問題なく考え方次第。顧客によっては完全冗長化というところがあり、この構成を紹介した。

・NSDとの速度差について
→NSDのほうが早い。理由は軽いから。
 KnotDNSはスケールアウトできるソフトとなっているためスペックが大きくなるほどKnotDNSのほうが早くなる。

・AWSのROUTE53などと連携可能かどうか?
→DNSゾーン転送が可能であれば、連携可能。

Debian Updates – 岩松 信洋氏

・Debianはフリー/オープンなOSを作成しようとするボランティベースのプロジェクト
・63カ国、約1000名の公式開発者が開発中(パッケージメンテナや翻訳も入れるともっと増える)
・Stretchは2017年のQ2またはQ3(4月-6月くらい)
・Debian Mini Conference
 いつかDebian Confを日本で実施するために、運営情報の取得や運営能力をアップさせるため。

Updates

2017年1月5日 Soft freeze 新しいパッケージの更新禁止
2017年2月5日 Full freeze パッケージの更新は止めてデバッグ
現在バグが153個あり、これが通ればDebian9が公開される。

・isoイメージが8.7.1であり今までと違い3つ数字があるが内容は変わらないため、気にしなくてよい。
・thunderbirdはバグが多く、debian9のリリースに間に合わなかった。
・古いCPUはサポート外となるため注意が必要
・テーマは Soft waves(デザイナーさんにて決定、デスクトップ画像など、Stretchの足をイメージ)
・LTSであるLinuxカーネル4.9.x、MariaDB 10.0.28、MySQL 5.7.17、PHP 7.1.1
・デバックシンボルパッケージがデフォルトで提供されたことにより、問題があった場合は、デバックしやすくなる

展示ブース

フューチャーアーキテクト株式会社

vulsのunknownは仕様?
→CVE登録されたときに、数値はまだ決まっていなかったり
 企業サイトには詳細があるけれども、CVEサイトには存在しない場合がある。
 それらはunknownとして登録される。

資料を確認するに
apt-get upgrade –dry-run
aptitude changelog
している模様。

日本 openSUSE ユーザ会

統合管理ツールYaST(ヤスト)が便利そうだった。
GUIで利用する場合に便利そうな印象を受けた。

Azure寺子屋第1回 を聞いた

Azure寺子屋第1回を聞いた。
その時のメモ。

日本でも使いやすいようにしている。

国家機密レベルの情報を保持可能。

DOD Level 5 PA granted to Microsoft Azure and Office 365


Azureは一番検討されているクラウドサービス。
左グラフ、青のラインが実際に利用しているクラウド。
緑のラインが検討したいクラウド。

ネットワーク速度

38リージョン存在する(AWSやGCPも圧倒する)
ネットワーク距離について東日本と西日本は2ms。
日本リージョンと東アジアリージョンは80ms。
米国リージョンまでだと130ms。

素晴らしいサイト

azureの基本的な情報を確認することが可能(制限やSLAなど)
http://azureplatform.azurewebsites.net/en-us/

Azureの状態

https://azure.microsoft.com/ja-jp/status/

LinuxSQL情報

WindowsSQLServerとLinuxSQLServerのAlwaysOnなどを試した人もいる。
権限周りにはまらなければ、意外と使えるらしい。

Dynamic Inventory – memo –

Ansible dynamic inventory + Zabbix APIで監視対象を動的に構成管理より
例えばローカルの/etc/hostsに存在するホスト名をinventoryとして使いたければ

inventory.sh
#!/bin/bash
HOSTS=$(cat /etc/hosts | grep -v ^# | awk '{print $2}')
HOSTS=$(echo "$HOSTS" | sed -e 's/^\(.*\)$/"\1"/g')
HOSTS=$(echo $HOSTS | sed -e 's/\s/,/g')
echo "{\"all\": {\"hosts\": [$HOSTS]}}"

のようなスクリプトを書いて渡してやるだけでいい。

Dynamic Inventoryを使ってみるより
ansibleは、インベントリファイルに実行権限が付いていなければ、通常のインベントリファイルとして読み込み、
実行権限が付いていれば実行した結果帰ってくるjsonを読み込むという処理をしているよう。

Dynamic Inventory

Dynamic Inventoryを一部意訳してみた。
たぶん誤訳もある。そして意味がわかりにくいところもある。

Topics

クラウドやLDAPやCobberなど違ったプラットフォーム上のシステムについて、
inventoryファイルを管理することが可能である。

Ansible TowerではDBにWEBやRESTからアクセスできるinventry情報を保持する。
またすべてのホスト情報もDBに持つことで、playbook履歴を追うことが可能。

Example: The Cobbler External Inventory Script

多くのハードウェアを管理しているAnsibleユーザがCobberを利用していると推測される。
(元Ansible, Incで働いていたMichael DeHaanが作成している)

…中略…

Example: AWS EC2 External Inventory Script

AWSを利用している場合、ホストの増減が発生するためinventoryファイルの管理は難しいため、
EC2 external inventory scriptを利用したほうがよい。

このスクリプトを利用するためには2つの方法がある。
1つめは-iオプションを利用してansibleコマンドを実行することである。

ansible -i ec2.py -u ubuntu us-east-1d -m ping

2つめはスクリプトを/etc/ansible/hostsにコピーし、chmod +xを実行する。
また ec2.iniを/etc/ansible/ec2.iniにコピーする。
そしていつも通りにansibleを実行すること。

AWSへのAPI呼び出しを正常に行うには、Boto(PythonインターフェイスをAWSに設定する)を設定すること。
利用可能なさまざまな方法がありますが、最も簡単なのは、2つの環境変数をエクスポートすることだけです。

export AWS_ACCESS_KEY_ID='AK123'
export AWS_SECRET_ACCESS_KEY='abc123'

スクリプトを実行して、正しく動作するか確認可能

cd contrib/inventory
./ec2.py --list

しばらくすると、すべてのリージョンのEC2 inventoryが表示される。
Botoプロファイルを利用して、複数AWSアカウントを管理する場合–profile PROFILEというオプションをec2.pyに渡す。
プロファイル例は以下となる。

[profile dev]
aws_access_key_id = <dev access key>
aws_secret_access_key = <dev secret key>

[profile prod]
aws_access_key_id = <prod access key>
aws_secret_access_key = <prod secret key>

ec2.py –profile prod を実行することで、prodアカウントのinventoryを取得できる。
(ただしansible-playbookではサポートされていない)
AWS_PROFILE=prod ansible-playbook -i ec2.py myplaybook.ymlといった形でansible-playbookを利用できる。
ec2.iniを編集することで使用していないリージョンを除くことなどが可能。

キャッシュコントロールや宛先変数をec2.iniで設定することも可能。
デフォルトではAWSのすべてのサービス用に設定されているが、コメントアウトすることで制御可能。
例えばRDSやelasticacheを利用しないのであれば、Falseを設定する。

[ec2]
...

# To exclude RDS instances from the inventory, uncomment and set to False.
rds = False

# To exclude ElastiCache instances from the inventory, uncomment and set to False.
elasticache = False

inventoryファイルは名前と宛先アドレスを結びつけるだけです。
デフォルトで設定としてEC2外からansibleを実施するようになっていますが、これは最も効率的な方法ではありません。

EC2内でansibleを実行している場合、内部DNSとIPの利用は外部DNS名を使うよりも理にかなっています。
この場合ec2.iniのdestination_variableを内部DNSとして編集できます。
VPCを利用している時に特に有用です。

EC2 external inventoryは複数のグループへのマッピングが可能です。
(Global,Instance ID,Region,Availability Zone,Security Group,Tagsなど)

–host=HOST オプションを利用して特定EC2で利用できる変数を取得できる。
(ec2_architecture,ec2_description,…,ec2_vpc_id)

インスタンスで利用できる変数取得方法

cd contrib/inventory
./ec2.py --host ec2-12-12-12-12.compute-1.amazonaws.com

AWS inventory script はキャッシュしてAPIを呼び出さないようにするため
ec2.iniにキャッシュしないように設定するか、以下コマンドを実施すること。

./ec2.py --refresh-cache

Example: OpenStack External Inventory Script

OpenStackベースのクラウドを利用している場合は動的インベントリを利用して(openstack.py)、
OpenStackから直接データを取得できる。
OpenStack inventory script は以下からダウンロード可能。
https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/openstack.py

ansibleコマンドで-i openstack.py と明示的に指定するか、/etc/ansible/hosts へスクリプトを置くことで利用可能。

…中略…

Other inventory scripts

CobblerやEC2だけでなく、以下についてもinventory scriptを利用可能。

BSD Jails
DigitalOcean
Google Compute Engine
Linode
OpenShift
OpenStack Nova
Ovirt
SpaceWalk
Vagrant (not to be confused with the provisioner in vagrant, which is preferred)
Zabbix

使い方の詳細は今後追加されるかもしれない。現状 contrib/inventory ディレクトリがわかりやすい。
基本的にAWSのスクリプトと同じ。

Ansible Best Practices

Best Practicesを意訳してみた。
たぶん誤訳もある。Google翻訳の精度が向上したことをすごく感じた。

Content Organization

次の章では、playbookを構成するさまざまな方法の1つを示します。
要望に合う形で改変してください。
なにがどうあってもroleは必ず利用してください!

Directory Layout

production                # inventory file for production servers
staging                   # inventory file for staging environment

group_vars/
   group1                 # here we assign variables to particular groups
   group2                 # ""
host_vars/
   hostname1              # if systems need specific variables, put them here
   hostname2              # ""

library/                  # if any custom modules, put them here (optional)
filter_plugins/           # if any custom filter plugins, put them here (optional)

site.yml                  # master playbook
webservers.yml            # playbook for webserver tier
dbservers.yml             # playbook for dbserver tier

roles/
    common/               # this hierarchy represents a "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if warranted
        handlers/         #
            main.yml      #  <-- handlers file
        templates/        #  <-- files for use with the template resource
            ntp.conf.j2   #  <------- templates end in .j2
        files/            #
            bar.txt       #  <-- files for use with the copy resource
            foo.sh        #  <-- script files for use with the script resource
        vars/             #
            main.yml      #  <-- variables associated with this role
        defaults/         #
            main.yml      #  <-- default lower priority variables for this role
        meta/             #
            main.yml      #  <-- role dependencies
        library/          # roles can also include custom modules
        lookup_plugins/   # or other types of plugins, like lookup in this case

    webtier/              # same kind of structure as "common" was above, done for the webtier role
    monitoring/           # ""
    fooapp/               # ""

Alternative Directory Layout

inventories/
   production/
      hosts               # inventory file for production servers
      group_vars/
         group1           # here we assign variables to particular groups
         group2           # ""
      host_vars/
         hostname1        # if systems need specific variables, put them here
         hostname2        # ""

   staging/
      hosts               # inventory file for staging environment
      group_vars/
         group1           # here we assign variables to particular groups
         group2           # ""
      host_vars/
         stagehost1       # if systems need specific variables, put them here
         stagehost2       # ""

library/
filter_plugins/

site.yml
webservers.yml
dbservers.yml

roles/
    common/
    webtier/
    monitoring/
    fooapp/

別の方法としてinventoryファイルとgroup_vars/host_varsを分割することが可能。
group_vars/host_vars がproductionとstagingで共通である必要が無い時はこちらの構成のほうが便利。

メリットは、より広い環境での柔軟性と異なる環境間での変数の完全な分離が可能であること。
デメリットは、ファイルが増えているため保守が難しいこと。

Use Dynamic Inventory With Clouds

クラウドを利用しているのであれば、Dynamic Inventoryを利用したほうがよい。
クラウドだけでなくシステムからサーバリストを出力できるような場合も、
Dynamic Inventoryを利用することができる。
(参考:Ansible dynamic inventory + Zabbix APIで監視対象を動的に構成管理)

How to Differentiate Staging vs Production

inventoryファイル分類方法をよく聞かれる。以下はそのよい例である。
グループ化方法を動的インベントリに適用することもできます。

以下の例ではすべての本番ホストがひとつのinventoryファイルに含まれています。
ホストの目的、データセンターの場所などに基づいてのグループ定義をオススメします。

# file: production

[atlanta-webservers]
www-atl-1.example.com
www-atl-2.example.com

[boston-webservers]
www-bos-1.example.com
www-bos-2.example.com

[atlanta-dbservers]
db-atl-1.example.com
db-atl-2.example.com

[boston-dbservers]
db-bos-1.example.com

# webservers in all geos
[webservers:children]
atlanta-webservers
boston-webservers

# dbservers in all geos
[dbservers:children]
atlanta-dbservers
boston-dbservers

# everything in the atlanta geo
[atlanta:children]
atlanta-webservers
atlanta-dbservers

# everything in the boston geo
[boston:children]
boston-webservers
boston-dbservers

Group And Host Variables

グループ化することですべてうまくいくわけではありません。変数を割り当てることも可能です。
例えばアトランタには独自のNTPサーバがある場合、

---
# file: group_vars/atlanta
ntp: ntp-atlanta.example.com
backup: backup-atlanta.example.com

WEBサーバ専用の変数は

---
# file: group_vars/webservers
apacheMaxRequestsPerChild: 3000
apacheMaxClients: 900

もしデフォルト値が存在する場合は

---
# file: group_vars/all
ntp: ntp-boston.example.com
backup: backup-boston.example.com

特定のハードウェアのみに適用する場合は(必要がなければ避けたほうがよいが)

---
# file: host_vars/db-bos-1.example.com
foo_agent_port: 86
bar_agent_port: 99

Dynamic Inventoryを利用する場合は、自動的にグループが作成されるため要注意。

Top Level Playbooks Are Separated By Role

site.yml:インフラストラクチャ全体を定義するplaybookが含まれている。そのためとても短い。

---
# file: site.yml
- include: webservers.yml
- include: dbservers.yml

webservers.ymlなどはグループとroleを指定するだけにすること。

---
# file: webservers.yml
- hosts: webservers
  roles:
    - common
    - webtier

webserversでの実行は2つの方法がある

ansible-playbook site.yml --limit webservers
ansible-playbook webservers.yml

Task And Handler Organization For A Role

以下はNTPサーバを設定するtaskファイルです。

---
# file: roles/common/tasks/main.yml

- name: be sure ntp is installed
  yum: name=ntp state=installed
  tags: ntp

- name: be sure ntp is configured
  template: src=ntp.conf.j2 dest=/etc/ntp.conf
  notify:
    - restart ntpd
  tags: ntp

- name: be sure ntpd is running and enabled
  service: name=ntpd state=started enabled=yes
  tags: ntp

以下がhandlerファイルとなります。タスクに変更があった場合最後に実行されます。

---
# file: roles/common/handlers/main.yml
- name: restart ntpd
  service: name=ntpd state=restarted

What This Organization Enables (Examples)

実行例について。
すべての構成を反映させる場合

ansible-playbook -i production site.yml

NTPのみを再構成する場合

ansible-playbook -i production site.yml --tags ntp

webserversを再構成する場合

ansible-playbook -i production webservers.yml

ボストンのwebserversを再構成する場合

ansible-playbook -i production webservers.yml --limit boston

10ホストずつ再構成する場合

ansible-playbook -i production webservers.yml --limit boston[1-10]
ansible-playbook -i production webservers.yml --limit boston[11-20]

基本的な使い方も可能

ansible boston -i production -m ping
ansible boston -i production -m command -a '/sbin/reboot'

有用なコマンドも覚えておくべき

# confirm what task names would be run if I ran this command and said "just ntp tasks"
ansible-playbook -i production webservers.yml --tags ntp --list-tasks

# confirm what hostnames might be communicated with if I said "limit to boston"
ansible-playbook -i production webservers.yml --limit boston --list-hosts

Deployment vs Configuration Organization

上記の設計モデルは典型的なもの。複数層でのデプロイが必要な場合はplaybookが追加され、
site.yml は deploy_exampledotcom.yml といったplaybookが追加されるかもしれないが、上記設計モデルと構成は変わらない。

1つのplaysにこだわらず、状況や目的に合わせてplaysを作成したほうがよい。

同じツールを利用してデプロイできるため、グループを再利用し、アプリケーション設定とは別のplaybookにOS設定を保存すればよい。

Staging vs Production

すでに記載しているがステージング環境と本番環境を別々にするためには inventory ファイルを別々にしたほうがよい。
1つのinventoryファイルにしてしまうと、予期せぬ動作をする可能性がある。

本番環境の前にステージング環境で試すことは非常に良いこと。サイズが違う場合は、グループ変数で制御すること。

Rolling Updates

‘serial’ キーワードを理解すること。これを利用して、制御すること。
Delegation, Rolling Updates, and Local Actions

Always Mention The State

stateパラメーターは多くのモジュールで利用されている。
‘state=present’や‘state=absent’についてplaybookに明示的に記載しておいたほうがよい。

Group By Roles

システムには複数のグループがある。
playbookは役割ごとに作成することが大切。

Operating System and Distribution Variance

異なるOS間でことなるパラメーターを利用する場合、group_by モジュールの利用がオススメ。
inventoryで定義しなくても、特定の条件に一致する動的なグループが作成される。

---

# talk to all hosts just so we can learn about them
- hosts: all
  tasks:
     - group_by: key=os_{{ ansible_distribution }}

# now just on the CentOS hosts...

- hosts: os_CentOS
  gather_facts: False
  tasks:
     - # tasks that only happen on CentOS go here

これによりすべてのホストがOSに基づいた動的グループに分類される。
グループ特有の設定が必要な場合は、以下のように設定します。

---
# file: group_vars/all
asdf: 10

---
# file: group_vars/os_CentOS
asdf: 42

上の例では、CentOSマシンはasdfに42の値を取得しますが、他のマシンは10になる。
これは変数の設定だけでなく、特定のシステムに特定の役割を適用するためにも使用できる。
変数だけが必要な場合は、OS名に基づいて変数が取り込むことも可能。

- hosts: all
  tasks:
    - include_vars: "os_{{ ansible_distribution }}.yml"
    - debug: var=asdf

Bundling Ansible Modules With Playbooks

libraryディレクトリがある場合、自動的にansibleのモジュールパスとして認識される。
playbookで実行されるモジュールを保持するためのよい方法。

Whitespace and Comments

空白を利用してわかりやすくすること、#でのコメントを推奨。

Always Name Tasks

タスクの名前は記載しなくてもよいが、タスクの目的を記載することを推奨。
playbook実行時に表示される。

Keep It Simple

とくかくシンプルに。ansibleのすべての機能を1度に使い分けてはいけない。
必要ないもの(vars,vars_files,vars_prompt,–extra-vars )は利用しないこと。

Version Control

gitなどのバージョン管理システムを利用し、変更した理由がわかるようにしておくこと。

Variables and Vaults

一般的な管理方法として、変数を見つけるためにgrepなどのツールが利用されます。
暗号化などで覆い隠されているときは、間接的に作業する必要があります。
playbook実行時に暗号化されていないファイルから変数を取得し
機密変数は暗号化されたファイルから取得します。

ベストプラクティスとして、group_vars/ のサブディレクトリを利用する。
vars と vault という2つのファイル名やプレフィックスを利用する。

rfc5077をインストールできなかった話

第2回社内セキュリティ共有勉強会に参加した際に初めて知った単語

TLSのセッション情報を確認できるツールらしい
結論としてdebian8で使ってみようとしたが、できなかった話

以下を参考に実施してみた
サーバ側のSSL Session Cache状況を確認する「rfc5077」というツールが便利
rfc5077-clientをDebian上でビルドしたい
を参考に実施した

# git clone https://github.com/vincentbernat/rfc5077.git
# aptitude install libnspr4-dev libev-dev libssl-dev libnss3-dev make gcc
...
# git submodule init
Submodule 'http-parser' (https://github.com/joyent/http-parser) registered for path 'http-parser'
Submodule 'httpagentparser' (git://github.com/shon/httpagentparser.git) registered for path 'httpagentparser'
# git submodule update
Cloning into 'http-parser'...
remote: Counting objects: 1460, done.
remote: Total 1460 (delta 0), reused 0 (delta 0), pack-reused 1460
Receiving objects: 100% (1460/1460), 659.95 KiB | 341.00 KiB/s, done.
Resolving deltas: 100% (897/897), done.
Checking connectivity... done.
Submodule path 'http-parser': checked out '1ca7de52587f19cb87a28b8ace2e0f2e6cfcde7f'
Cloning into 'httpagentparser'...
remote: Counting objects: 591, done.
remote: Total 591 (delta 0), reused 0 (delta 0), pack-reused 591
Receiving objects: 100% (591/591), 630.40 KiB | 160.00 KiB/s, done.
Resolving deltas: 100% (265/265), done.
Checking connectivity... done.
Submodule path 'httpagentparser': checked out '920af88989f6dd8eb6f628505d039df8b65c880e'
# make
cc -g -Werror -Wall -ansi -std=c99 -D_DEFAULT_SOURCE -D_GNU_SOURCE   -c -o rfc5077-client.o rfc5077-client.c
rfc5077-client.c: In function ‘resultinfo_display’:
rfc5077-client.c:135:6: error: implicit declaration of function ‘SSL_SESSION_get0_cipher’ [-Werror=implicit-function-declaration]
      SSL_CIPHER_get_name(SSL_SESSION_get0_cipher(x)),
      ^
rfc5077-client.c:135:26: error: passing argument 1 of ‘SSL_CIPHER_get_name’ makes pointer from integer without a cast [-Werror]
      SSL_CIPHER_get_name(SSL_SESSION_get0_cipher(x)),
                          ^
In file included from rfc5077-client.c:23:0:
/usr/include/openssl/ssl.h:1834:13: note: expected ‘const struct SSL_CIPHER *’ but argument is of type ‘int’
 const char *SSL_CIPHER_get_name(const SSL_CIPHER *c);
             ^
rfc5077-client.c:154:5: error: implicit declaration of function ‘SSL_SESSION_get_master_key’ [-Werror=implicit-function-declaration]
     size_t master_key_len = SSL_SESSION_get_master_key(x, NULL, 0);
     ^
rfc5077-client.c:170:6: error: implicit declaration of function ‘SSL_SESSION_has_ticket’ [-Werror=implicit-function-declaration]
      SSL_SESSION_has_ticket(x)?"✔":"✘",
      ^
rfc5077-client.c: In function ‘resultinfo_write’:
rfc5077-client.c:207:33: error: passing argument 1 of ‘SSL_CIPHER_get_name’ makes pointer from integer without a cast [-Werror]
             SSL_CIPHER_get_name(SSL_SESSION_get0_cipher(x)),
                                 ^
In file included from rfc5077-client.c:23:0:
/usr/include/openssl/ssl.h:1834:13: note: expected ‘const struct SSL_CIPHER *’ but argument is of type ‘int’
 const char *SSL_CIPHER_get_name(const SSL_CIPHER *c);
             ^
rfc5077-client.c: In function ‘main’:
rfc5077-client.c:381:3: error: implicit declaration of function ‘TLS_client_method’ [-Werror=implicit-function-declaration]
   if ((ctx = SSL_CTX_new(TLS_client_method())) == NULL)
   ^
rfc5077-client.c:381:26: error: passing argument 1 of ‘SSL_CTX_new’ makes pointer from integer without a cast [-Werror]
   if ((ctx = SSL_CTX_new(TLS_client_method())) == NULL)
                          ^
In file included from rfc5077-client.c:23:0:
/usr/include/openssl/ssl.h:1820:10: note: expected ‘const struct SSL_METHOD *’ but argument is of type ‘int’
 SSL_CTX *SSL_CTX_new(const SSL_METHOD *meth);
          ^
cc1: all warnings being treated as errors
<builtin>: recipe for target 'rfc5077-client.o' failed
make: *** [rfc5077-client.o] Error 1

第2回社内セキュリティ共有勉強会に参加した

第2回社内セキュリティ共有勉強会に参加した。テーマは「メール」
その際のメモ

メールとZIPと他人の秘密

添付メールを利用せずに、クラウドを利用しましょう

デメリット

・誤送信した際に覗かれる
→例えばUSBを拾った人の45%は中身を覗くらしい
 http://ascii.jp/elem/000/001/213/1213231/
・暗号化が弱い可能性

メリット

・クラウドはサービス管理者に守られている
・守りが破られたときに、共有を解除できる
・環境依存が少ない

参考

パスワードが脆弱かどうかわかるサイト
https://howsecureismypassword.net/

社会人による衛生開発の実情と情報リスクの共有

ライフワーク:誰もが宇宙目指せる世界を作る
リーマンサットスペーシス:民間で人工衛星を制作している
民間が宇宙に行けるような法整備がされているとのこと
→キャノンが小さなロケット制作?など

Home

CSIRTでなくても回る仕組みづくり(仮題)

ポイントは
・できるところから
・解決することを優先する

セキュリティはhowto(どうすればよいか)を聞かれることが多い
守るものは何か?
→情報資産(売上、顧客情報…)

そのためにどう守るか?
 コンピューターを守る
 ある程度の決め事を作る
 →実はCSIRTではなくても当たり前にできること

正しく運用するためには?
 当事者文化をつくる
 ダメなルールはさっさと直していく

セキュリティ投資の必要性を経営層に納得してもらった方法

セキュリティ予算を勝ち取る方法

経営陣がセキュリティを経営課題として認識していない
 現状認識→可視化。ウィルス対策ソフトがインストールされていなかったため、無料のウィルススキャンを実施
 セキュリティの事例を共有→ZMPの上場延期
 経営陣のプロトコルを合わせる→経営陣に伝わる言葉を。DDoS攻撃、ではなくその結果事業が停止されることを伝える

リスク対応の優先度は、頻度と影響度(インシデントが事業に与えるダメージ)を考慮して算出している

脆弱性スキャナVulsを使ってDevSecOpsを実践!-牛田さん

脆弱性スキャナVulsのビューアVulsRepo
2016年だけでCVE-IDは約6600件。人で判断するのは不可能
→脆弱性チェックの自動化が必要

1.脆弱性情報収集→2.対象マシン調査→3.対策、パッチ適用→4.本番適用
1,2を自動で可視化してくれるツール

メリットとして
・エージェントモード可能、モジュールを配置するのみ
→SSHがないようなサーバでも利用可能、fluentdについて
・rubyのライブラリなども拾うことが可能(設定を変更する必要がある)
・日本語、レポート手段が豊富

Email、Slack通知に対応している

閲覧方法も様々
 小規模→TUI,Web,Excel
 大規模→QuickSight(クラウド),ElasticSearch+kibana

Zabbixで登録されたホストをVulsでチェックするなども可能
(Zabbixに登録されたホスト情報を脆弱性スキャナVulsへ自動連携する)

Vulsのスキャンの負荷はどれくらいあるのか?
→実施していることは yum であれば update と changelog だけであるため、そんなに負荷はかからない

「ページがモバイルフレンドリーではありません」対策

Googleの検索結果に「ページがモバイルフレンドリーではありません」といった表示がされていた

モバイルフレンドリーテストを実施した結果

[WPtouch Mobile Plugin]をインストールした
モバイル端末で見ると最適化されたデザインのテーマを表示してくれるプラグイン

モバイルからみると、どこかでみたことのあるようなサイトに変身!

参考URL

WordPressサイトをあっという間にモバイルフレンドリーにする無料プラグイン8選