もう「サーバーレスだけどサーバあるじゃん」という話をしたくない - めもおきば
3年ぐらい同じ事を言い続けてるんだけど、そもそもサーバーレスという言葉の由来はソフトウェアアーキテクチャの話*1。 一つのタスクの実行期間を超えて、ファイルシステムやメモリ上の変数などサーバ固有のリソースに依存しないという、12 Factor Appから死ぬほど言われ続けている制約を満たすプログラミングモデルがサーバーレスの本質です。この制約に視点を置くとサーバーレスとしか言いようがない。 これを真面目にやろうとすると、キューやPub/Subによる非同期タスク（イベント駆動）が必要になってきます。これを整理したのがリアクティブシステム、わかりやすく関数という枠にはめたのがAWS LambdaをはじめとするFaaSです。 その一方で、これを満たしたソフトウェアは、AWSなりAzureなりGCPなりクラウド基盤側が勝手にサーバを増やしたり減らしたりできて、完全従量制にできたりメリットがたくさん
2016年のサーバレスアーキテクチャ総まとめ - めもおきば
この記事は、Serverless Advent Calendar 2016の16日分(だったはずのもの)です。 なんとかクリスマスまでには間に合ったのでお許しくださいorz まとめ AWS Lambdaの功罪で混在されがちな概念が整理されて議論されるようになった 提供されるBaaSのみを使ってリッチアプリケーションを開発する手法 フルマネージドなFaaSの実行環境 高水準コンポーネントをイベントで接続するリアクティブシステム 主要各社のFaaS実行環境が揃ってきた AWS Lambda Azure Functions (2016-11-15 GA!) IBM OpenWhisk (2016-12-14 GA! おめでとうございます!) Google Cloud Functions (2016-02-13 Alpha) 国内のニフティクラウドからも サーバレスアーキテクチャにまつわる様々な動
VENOM(CVE-2015-3456) 影響範囲メモ - めもおきば
Xen, KVM等の、仮想化ハードウェアとしてQEMUを利用している環境で発生 VMware,Bochsは対象外 Hyper-VもXenと仮想化コアは同じだが仮想化ハードウェアが違うので対象外 Xen利用のAWSは対象外。自前でFDCを外している？*1 おそらくVirtualBoxも対象？ FDドライブを接続していなくても、QEMUの仮想化ハードウェア(ICH9)がFDコントローラを積んでいるので対象となる。 This issue affects all x86 and x86-64 based HVM Xen and QEMU/KVM guests, regardless of their machine type, because both PIIX and ICH9 based QEMU machine types create ISA bridge (ICH9 via LPC) a
うるう秒まとめ - めもおきば
今年は、2015/07/01 08:59:60 JST としてうるう秒が挿入されます！(うるう秒実施日一覧) 「うるう秒なんてきちんと処理したくない」という人向けのまとめ。 まとめっぽい記事 7/1の閏秒を迎えるにあたってLinuxでは何をすべきか？ TECHNICAL ASPECTS OF LEAP SECOND PROPAGATION AND EVALUATION うるう秒の問題（Windows、SQL Server、MySQL、.NET Framework） NICT うるう秒実施に関する説明会: うるう秒説明資料 【レポート】2015年7月1日実施のうるう秒についての説明会 (NVS) AWS AWS側コンポーネント: 前後12時間ずつ、計24時間かけて調整する。 EC2: ntp.orgとか自前管理(共有責任モデル)、デフォルトだとntp.org/time.windows.com
脆弱性の危険度(ざっくり) - めもおきば
まあCVSSの解説見ろよって話なんだけど、ありがちな脆弱性の危険度は個人的にはこんなイメージです。 総合的な危険度 ＝ 条件 × 影響 条件 脆弱性の攻撃に必要な前提条件が「狭い」のであればそれほど問題ないです。 一番ヤバイ: TCPやUDP、IPによりネットワークから送られた通信で攻撃が成立 Slammer(しかもハンドシェークが不要なUDPのため被害が拡大) Heartbleed Shellshock、GHOST(ただし一部のミドルウェア) だいぶヤバイ: 通信路に割り込まないとイケない(MITM) *1 アクティブに通信に割り込むかどうかで度合いが変わる POODLEとか FREAK そこそこヤバイ: ネットワーク経由での攻撃ができるが、認証後でないと成立しない ヤバイ: ログイン後の一般ユーザーで攻撃が成立 ちょっとヤバイ: 弱い設定をしている場合など限られた条件でのみ攻撃が成立
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
glibcを更新しても大丈夫な「正しい」タイムゾーンの設定方法 (2/3追記あり) - めもおきば
RHEL, CentOS, Amazon Linux (6以前) /etc/localtime を /usr/share/zoneinfo 以下から上書きしたりシンボリックリンク張ったりという手法が横行していますが、 /etc/localtime は glibc パッケージに含まれるためパッケージを更新すると上書きされてESTとかに戻ってしまうわけです。 当然ながら、ディストリビューションとして正しい設定方法が用意されているので、こちらを使います。 /etc/sysconfig/clock にタイムゾーンを書きます。*1sudo sed -i -e "s/^ZONE/#ZONE/g" -e "1i ZONE=\"Asia/Tokyo\"" /etc/sysconfig/clock tzdata-update を実行します。sudo /usr/sbin/tzdata-update これだけで
Ameba等で利用しているOpenStack Swiftを利用したオブジェクトストレージ - めもおきば
CyberAgent エンジニア Advent Calendar 2014 5日目です。 5日目は、インフラ＆コアテク本部の@nekoruriが担当します。 ← 4日目 Unity×ADXでつくる音ゲーの話 アメーバピグへのGoogle BigQuery導入までのもろもろ設定記 → 私たちが所属するインフラ＆コアテク本部は、「(^q^)くおえうえーーーるえうおおおｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」でお馴染みアニメ放映中のガールフレンド(仮)やアメブロを初めとするAmeba、755などグループ会社に対して、最適化されたサービスインフラとその運用ノウハウを提供する組織です。自社開発のプライベートクラウドの開発・運用だけでなく、パブリッククラウドやCDNなどの外部サービスの活用支援や、サービスに関するセキュリティプロセスなど、「サービスを動かす基盤」全体の向上に責任を負っています。 今日は、インフ
ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば
条件1. /bin/shの実体がbashのディストリビューション RHEL CentOS Scientific Linux Fedora Amazon Linux openSUSE Arch Linux (自ら設定した場合: Debian, Ubuntu) 条件2. 動作環境 CGI (レンタルサーバでありがちなCGIモードのPHP等も含む) Passenger(Ruby) 条件3. プログラム内容 Passengerは全死亡 *1 systemや `command`、 '| /usr/lib/sendmail' などで外部コマンド実行 *2 PHPのmailやmb_send_mail、その他フレームワーク等を介したメール送信 *3 以下は条件1が不要 明示的にbashを呼ぶ 先頭で #!/bin/bash や #!/usr/bin/env bash しているプログラムを実行 (rbenv
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
