Windows10 が勝手にスリープする

Surface Pro 5 の Windows 10 で突然スリープになることがある。
スリープの設定なども見直してみたが、原因がわからず以下の記事を参考に対応してみた。
Windows10が数分で勝手にスリープする原因と解決方法

対応内容としては
How to Add or Remove “System unattended sleep timeout” in Power Optionsから
[Add_System_unattended_sleep_timeout.reg]をダウンロードする。

実行(レジストリ追加)後に、電源の詳細に新しく[システム無人スリープタイムアウト]が出てくるようになるため、こちらの時間を延ばす。

これで様子見。

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のスクリプトと同じ。